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Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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Scope 



The present document covers both online and offline charging for the IMS. For clarity, the terms Offline Charging and 
Online charging as applied to the IMS are defined here in clause 3. These definitions are the same as listed in 
TS 32.200 [2]. 

The IMS charging architecture details, requirements, definitions and principles are listed in TS 32.200 [2] and therefore 
are not repeated here. 

In the present document the charging data triggers, message content and format are specified along with the transport of 
these messages using the Diameter protocol. Details about charging message flows and the definitions of the Diameter 
AVPs are also included in the present document. This information is divided into two main clauses: Online Charging 
and Offline Charging. 
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Definitions, symbols and abbreviations 



3.1 



Definitions 



For the purposes of the present document, the following terms and definitions apply: 

offline charging: charging mechanism where charging information does not affect, in real-time, the service rendered 

online charging: charging mechanism where charging information can affect, in real-time, the service rendered and 
therefore a direct interaction of the charging mechanism with session/service control is required 



3.2 Symbols 

For the purposes of the present document, the following symbols apply: 



Bi 
Rb 
Re 
Re 
Rf 
Ro 



The Interface between the IMS charging function and the BS 

Online Charging Reference Point between Session Charging Function and Correlation Function 

Online Charging Reference Point between ECF and Correlation Function 

Online Charging Reference Point towards a Rating Server 

Offline Charging Reference Point between an IMS Network Entity or an AS and CCF 

Online Charging Reference Point between an AS or MRFC and the ECF 



3.3 



Abbreviations 



For the purposes of the present document, the abbreviations defined in TR 21.905 [1], TS 32.200 [2] and the following 
apply: 



ABNF 
ACA 
ACR 
AS 



Augmented Backus-Naur Form 
Accounting Answer 
Accounting Request 
Application Server 
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AVP Attribute Value Pair 

B2BUA Back-to-Back User Agent 

BGCF Breakout Gateway Control Function 

BS Billing System 

CCF Charging Collection Function 

CDR Charging Data Record 

CPCF Content Provider Charging Function 

ECF Event Charging Function 

ECUR Event Charging with Unit Reservation 

CSCF Call Session Control Function (I-Interrogating; P-Proxy; and S-Serving) 

lEC Immediate Event Charging 

IMS IP Multimedia Subsystem 

ISC IMS Service Control 

MGCF Media Gateway Control Function 

MRFC Media Resource Function Controller 

MRFP Multimedia Resource Function Processor 

OCS Online Charging System 

SCCF Subscriber Content Charging Function 

SDP Session Description Protocol 

SIP Session Initiation Protocol 

UA User Agent 

UE User Equipment 



4 Offline and Online Charging 

4.1 Implementation of Offline and Online Charging 

The IMS charging architecture, described in TS 32.200 [2], specifies that for offline charging all communications 
between the IMS network entities and the CCF are carried out on the Rf interface. On the other hand, for online 
charging the Ro interface is used by the AS and MRFC towards the Event Charging Function and the ISC interface is 
used between the S-CSCF and the Session Charging Function. The rules governing the selection of the proper interfaces 
are described in the subclauses below. 

4.1 .1 Usage of Rf and Ro Interfaces 

The AS and MRFC are able to distinguish whether to apply offline or online charging, i.e. whether to send charging 
information on the Rf interface to the CCF or on the Ro interface to the ECF (or to use both). The decision of which 
interface to use is based on the information (CCF and/or ECF address) the AS/MRFC receive in the SIP signalling and 
the system configuration as provisioned by the operator. If the AS/MRFC only receive the CCF address and do not 
receive an ECF address then they use only the Rf interface. If only the ECF address was provided then they use only the 
Ro interface. In cases where both CCF and ECF addresses are provided it is possible to use both interfaces 
simultaneously. 

However, operators may overrule the addresses received via the SIP signalling and use their own configured rules 
instead. Operators may configure locally on the AS/MRFC an ECF and/or CCF address. The CCF address may be 
locally configured on all other IMS nodes. The choice of whether the IMS nodes use the locally configured addresses or 
the addresses received by SIP signalling, and the decision on which interface(s) to use, is left for operator configuration. 



4.1 .2 Usage of Rf and ISC Interfaces 



All other IMS nodes (S-CSCF, P-CSCF, I-CSCF, BGCF and MGCF) apply offline charging via the Rf interface using 
the CCF address as received via SIP signalling or the locally configured CCF address. The S-CSCF supports online 
charging using the ISC interface, i.e. if the application server addressed over ISC is the Session Charging Function of 
the OCS. 
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4.1 .3 Support of Local File Storage 



The present document does not mandate the support of persistent storage on the IMS nodes nor does it require any 
protocol except Diameter to be used for either onHne or offline charging. However, if an IMS node supports a local 
persistent storage media, the IMS application may copy the accounting information sent to the Diameter client to this 
local filestore. Operator's post-processing systems may then pull the contents of the filestore via FTP applying the same 
file transfer procedures as those specified for the 'Bi' interface. Further details are implementation specific and are out of 
the scope of standardisation. 

4.2 Diameter Protocol Basic Principles and Use 

The present document defines a 3GPP IMS charging Diameter application, which utilizes the Diameter Base Protocol 
[3]. This application is used for both online and offline charging. The generic description of the protocol is provided in 
the subclauses below while the portions of the protocol application associated with offline and online charging are 
described in clauses 5 and 6, respectively. 

4.2.1 Basic Principles 

The IMS charging Diameter application is based on the following general principles: 

• The basic functionality of Diameter, as defined by the Diameter Base Protocol [3] is re -used in IMS. 

• For offline charging IMS network elements report accounting information to the Charging Collection Function 
(CCF). The CCF uses this information to construct and format CDRs. 

• For online charging, the AS and MRFC in the IMS network report accounting information to the Event Charging 
Function (ECF). The ECF uses this information to support the event based charging (content charging) function 
of the DCS. 

4.2.2 Application Requirement for the Base Protocol 

4.2.2.1 Offline Specific Base Protocol Requirements 

A configurable timer is supported in the CCF to supervise the reception of the ACR [Interim] and/or ACR [Stop]. An 
instance of the Timer' is started at the beginning of the accounting session, reset on the receipt of an ACR [Interim] and 
stopped at the reception of the ACR [Stop]. Upon expiration of the timer, the CCF stops the accounting session with the 
appropriate error indication. 

For offline charging, the client implements the state machine described in [3]. The server (CCF) implements the 
STATELESS ACCOUNTING state machine as specified in [3], i.e. there is no order in which the server expects to 
receive the accounting information. 

4.2.2.2 Online Specific Base Protocol Requirements 

The usage and values of Acct-Inte rim-Interval AVP and the timer Ts' are under the sole control of the credit control 
server (OCS) and determined by operator configuration of the OCS. There are no specific requirements on the client 
concerning the Acct-Inte rim-Interval AVP population in the ACR. 

The online cHent (e.g. AS, MRFC) implements the state machine described in [13] for "CLIENT, EVENT BASED" or 
"CLIENT, SESSION BASED", i.e. when the client applies Immediate Event Charging (lEC) it uses the "CLIENT, 
EVENT BASED" state machine, or when the client applies Event Charging with Unit Reservation (ECUR) it uses the 
"CLIENT, SESSION BASED" state machine. 

The online charging server that is part of the OCS implements the state machine described in [13] for the "SERVER, 
SESSION AND EVENT BASED" in order to support Immediate Event Charging and Event Charging with Unit 
Reservation. 

4.2.2.3 Security Considerations 

Diameter security is addressed in the base protocol [3]. Network security is specified in TS 33.201 [4]. 
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5 Offline Charging 

5.1 Diameter Description on the Rf Interfaces 
5.1.1 Basic Principles 

The offline charging functionaHty is based on the IMS network nodes reporting accounting information upon reception 
of various SIP methods or ISUP messages, as most of the accounting relevant information is contained in these 
messages. This reporting is achieved by sending Diameter AccoMnf/n^ Requests (ACR) [Start, Interim, Stop and Event] 
from the IMS nodes to the CCF and/or ECF. 

The Diameter client uses ACR Start, Interim and Stop in procedures related to successful SIP sessions. It uses ACR 
Events for unsuccessful SIP sessions and for session unrelated procedures. Further details are specified in the tables 
below and in subclause 5.1.2. 

It is operator configurable in the nodes for which SIP method or ISUP messages an Accounting Request is sent, with the 
exception that if accounting information is collected for sessions the ACR [Start] and ACR [Stop] messages are 
mandatory according to the tables below. Table 5.1 describes all possible ACRs that might be sent from a P-CSCF, 
I-CSCF, S-CSCF, MGCF or BGCF. A Hst of node specific ACRs, along with the AVPs to be included are detailed in 
section 5.1.3.3. 

The ACRs to be sent from a MRFC are described in table 5.2. 

In the tables below, the terms "configurable" implies that operators may enable or disable the generation of an ACR 
message by the IMS node in response to a particular "Triggering SIP Method /ISUP Message". However, for those table 
entries marked with *, the operator can enable or disable the ACR message based on whether or not the SIP (Re) Invite 
message that is replied to by the "Triggering SIP Method /ISUP Message" carried piggybacked user data. 

Table 5.1 : Accounting Request Messages Triggered by SIP Methods or ISUP Messages 
for all IMS nodes except for MRFC and AS 



Diameter 
Message 


Triggering SIP Metliod /ISUP Message 


Mandatory/ 
Configurable 


ACR [Start] 


SIP 200 OK acknowledging an initial SIP INVITE 


Mandatory 


ISUP:ANM (applicable for the MGCF) 


Mandatory 


ACR [Interim] 


SIP 200 OK acknowledging a SIP 

RE-INVITE or SIP UPDATE [e.g. change in media components] 


Configurable 


Expiration of AVP [Acct-lnterJm-lnterval] 


Configurable 


ACR [Stop] 


SIP BYE message (both normal and abnormal session termination cases) 


Mandatory 


ISUP:REL (applicable for the MGCF) 


Mandatory 


ACR [Event] 


SIP 200 OK acknowledging non-session related SIP messages, which are: 
SIP NOTIFY 
SIP MESSAGE 
SIP REGISTER 
SIP SUBSCRIBE 


Configurable 
Configurable 
Configurable 
Configurable 


SIP Final Response (4xx, 5xx or 6xx), indicating an unsuccessful SIP session set-up 


Configurable * 


SIP Final Response (4xx, 5xx or 6xx), indicating an unsuccessful session-unrelated 
procedure 


Configurable * 


SIP CANCEL, indicating abortion of a SIP session set-up 


Configurable * 


I-CSCF completing a Cx Query that was issued in response to a SIP INVITE 


Configurable 


NOTE: SIP SUBSCRIBE with the field "Expires" set to means unsubscribe. SIP REGISTER with its "Expires" 
header field or "Expires" parameter equal to means Deregistration [14]. 
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Table 5.2: Accounting Request Messages Triggered by SIP Methods for the MRFC 



Diameter 
IVIessage 


Trigger 


Mandatory/ 
Configurable 


ACR [Start] 


SIP 200 OK acknowledging an SIP INVITE for initiating a multimedia ad hoc 
conferencing session 


IVlandatory 


ACR [Interim] 


SIP ACK acknowledging a SIP INVITE to connect an UE to the conferencing session 


Configurable 


Expiration of AVP [Acct-lnterim-lnterval] 


Configurable 


ACR [Stop] 


SIP BYE message 


Mandatory 


SIP Final Response with error codes 4xx, 5xx or 6xx indicating termination of an ongoing 
session 


l\/landatory 



ASs support all four ACR types (Start/Interim/Stop/Event). The use of ACR Start, Interim and Stop (Session Charging) 
versus ACR Event (Event Charging) depends on the services provided by the application server. Example flows for an 
AS employing Event Charging and an AS using Session Charging are shown in subclause 5.1.2.1.3. 

The ability of SIP methods not listed in tables 5.1 and 5.2 to trigger ACRs is for further study. 
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5.1 .2 Message Flows and Types 



The flows described in the present document specify the charging communications between IMS entities and the 
charging functions for different charging scenarios. The SIP messages associated with these charging scenarios are 
shown primarily for general information and to illustrate the charging triggers. They are not intended to be exhaustive 
of all the SIP message flows discussed in TS 24.228 [12]. 

5.1 .2.1 Message Flows - Successful Cases and Scenarios 

5.1.2.1.1 Session Related Procedures 



5.1.2.1.1.1 



Session Establishment - Mobile Origination 



Figure 5.1 shows the Diameter transactions that are required between CSCF and CCF during session establishment 
originated by a UE. 



Visited Network 



Home Network 



UE 



1. INVITE 




2. 200 OK 




P-CSCF 



CCF 

(visited) 



I. INVITE 



S-CSCF 



CCF 

(home) 



Service Control 



1. INVITE 



More SIP signalling 



2. 200 OK (Invite) 



5. Accounting Request [Start] 



2. 200 OK (Invite) 



Service Control 



Open a P-CSCF CDR 



6. Accounting Ansv 

K 



3. Accounting Request [Start] 




Open a S-CSCF CDR 



4. Accounting Answe 

K 



More SIP signalling 




SIP Session established 



1. 

2. 
3. 



4. 
5. 
6. 



"1 1 1 1 1 

Figure 5.1 : Message Sequence Chart for Session Establishment (Mobile Origination) 

The session is initiated. 

The destination party answers and a final response is received. 

Upon reception of the final response, the S-CSCF sends an Accounting-Request with 

Accounting-Record-Type indicating START_RECORD to record start of a user session and start of 

a media component in the S-CSCF CDR. 

The CCF acknowledges the reception of the data and opens a S-CSCF CDR. 

Same as 3, but for P-CSCF. 

Same as 4, but creating a P-CSCF CDR. 
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5.1.2.1.1.2 



Session Establishment - Mobile Termination 



Figure 5.2 shows the Diameter transactions that are required between CSCF and CCF during a session establishment 
that is terminated to a mobile. The I-CSCF is only involved in the INVITE transaction. 



visited Network 



Home Network 



UE 



P-CSCF 




CCF 

(visited) 



CCF 

(liome) 



Cx Query with the HSS 



2. Accounting Request 



Create I-CSCF CDR 



Service Control 



3. Accounting Answer ^ 



More SIP signalling 



>. Accountini 




ing Reque^ [Start] 



Open P-CSCF CDR 



6. Accounting Answei 
4 



7. Accounting Requ<^ t [Stai 



Open S-CSCF CDR 



8. Accounting Answe 
•4 



More SIP signalling 



[Event] 





SIP Session established 



Figure 5.2: Message Sequence Chart for Session Establishiment (IVIobile Termination) 



1. 

2. 

3. 
4. 
5.- 



The session is initiated. 

Upon completing a Cx query the I-CSCF sends an Accounting Request with the 

Accounting-Record-Type set to EVENT. 

The CCF acknowledges the data received and creates an I-CSCF CDR. 

The destination party answers and a final response is sent. 

These steps are identical to the corresponding steps described in subclause 5.1.2.1.1.1. 
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5.1.2.1.1.3 



Mid-Session Procedures 



Figure 5.3 shows the Diameter transactions that are required between CSCF and CCF when a UE generates a SIP 
(Re-)INVITE or SIP UPDATE in mid-session, e.g. in order to modify media component(s), or when the hold and 
resume procedure is executed. 



Visited Networli 



Home Network 



CCF 

(visited) 



I 



CCF 

(iiome) 



SIP Session ongoing 



1. INVITE/ 
UPDATE 




1. INVITE/ 
UPDATE 



Service Control 



I. INVITE/ 
UPDATE 



More SIP signalling 



1. 200 OK (Invite/L pdate) 



2. 200 OK (Invite/Update) 



5. Accounting Requ ;st [Interim] 



2. 200 OK (Invite/U] idate) 



Service Control 



Update tlie P-CSCF CDR 



6. Accounting Answejr 



3. Accounting Request [Interim] 




Update the S-CSCF CDR 



4. Accounting Answer 



SIP Session continues 



Figure 5.3: Message Sequence Chart for Media Modification 



1. 

2. 
3. 



4. 
5. 
6. 



Modified media information is received from the subscriber. 

The destination party acknowledges the media modification. 

At modification of a media, the S-CSCF sends Accounting-Request with Accounting-Record-Type 

indicating INTERIM_RECORD to record modification of a media component in the S-CSCF 

CDR. 

The CCF acknowledges the reception of the data and updates the S-CSCF CDR. 

Same as 3, but for P-CSCF. 

Same as 4, updating the P-CSCF CDR. 
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5.1.2.1.1.4 



Session Release - Mobile Initiated 



Figure 5.4 shows the Diameter transactions that are required between CSCF and CCF for a session release that is 
initiated by the UE. 



UE 



Visited Network 



fi. 200 OK 



P-CSCF 



CCF 

(visited) 



l.BYE 



2. Accounting Req^e ^t [Stop] 



Close the P-CSCF CDR 



3. Accounting Answt r 



6. 200 OK 



Home Networli 



S-CSCF 



CCF 

(home) 



Service Control 



l.BYE 



4. Accounting Reque it [Stop] 



Close the S-CSCF CDR 



^. Accounting 



AnsW' :r 



6. 200 OK 



Figure 5.4: Message Sequence Chart for Session Release 



1. 

2. 



3. 
4. 
5. 
6. 



The session is released. 

At session termination the P-CSCF sends Accounting-Request with Accounting-Record-Type 

indicating STOP_RECORD to record stop of a session and stop of a media component in the 

P-CSCF CDR. 

The CCF acknowledges the reception of the data and closes the P-CSCF CDR. 

Same as 2, but for S-CSCF. 

Same as 3, closing the S-CSCF CDR. 

The release is acknowledged. 
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5.1.2.1.1.5 



Session Release - Network Initiated 



In the case of network initiated session release the IMS node sends a SIP BYE message which is replied to by the UE 
with a SIP 200 OK message. The charging message flow for this case is identical to the mobile initiated session release 
described in subclause 5.1.2.1.1.4. 



5.1.2.1.1.6 



Session Release - CCF initiated 



The IMS operator may request the release of SIP session(s) upon certain trigger conditions being met, for example as 
soon as a fraud is detected. 

Figure 5.5 shows the Diameter transactions that are required in order to release an ongoing SIP session. 



UE 



Visited Network 



Home Network 



P-SCSF 



CCF 

(visited) 



S-CSCF 



CCF 

(home) 



SIP Session ongoing 



l.BYE 



6. 200 OK 



2. Accounting Reqi est [Stop] 



l.BYE 



Close the P-CSCF CDR 



3. Accounting Answ 



7. 200 OK 



l.BYE 



4. Accounting Request [Stop] 




Figure 5.5: Message Sequence Chart for Network Initiated Session Release 



1. 



2. 



3. 
4. 
5. 
6. 



The S-CSCF initiates the SIP session release by sending SIP BYE request to both the originating 

and the terminating parties, as specified in TS 23.218 [5]. 

At session termination the P-CSCF sends Accounting-Request with Accounting-Record-Type 

indicating STOP_RECORD to record stop of a session and stop of a media component in the 

P-CSCF CDR. 

The CCF acknowledges the reception of the data and closes the P-CSCF CDR. 

Same as 2, but for S-CSCF. 

Same as 3, but for S-CSCF CDR. 

The S-CSCF receives the 200 OK responses from originating and terminating parties. 
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5.1.2.1.2 



Session-Unrelated Procedures 



Figure 5.6 shows the Diameter transactions that are required between CSCF and CCF for session-unrelated IMS 
procedures, i.e. those that relate to the Diameter ACR [Event], as listed in table 5.1. 



visited Network 



Home Network 



UE 




P-CSCF 



1. SIP Request (e.g. 

> 



2. SIP Response 



CCF 

(visited) 



SUBSCRIBE) 
1 . SIP Request (e.g. 



S-CSCF 



SUBSCRIBE) 



CCF 

(iiome) 



Service Control 



More SIP signalling 



2. SIP Response 



5. Accounting Requi st [Event] 



Req\jt 



Create P-CSCF CDR 



6. Accounting Answer 



3. Accounting Request [Event] 




Create S-CSCF CDR 



4. Accounting AnsW' '.r 



Figure 5.6: Message Sequence Chart for Session-Unrelated Procedure 



1. 

2. 



The P-CSCF receives a "SIP Request" (e.g. SUBSCRIBE) from the subscriber. 
The "SIP Request" is acknowledged by the "SIP Response" as follows: 

in the successful case, a 200 OK message is returned; 

in case of failure an appropriate SIP error message is returned. 



Depending on the used SIP method, there might be additional signalling between steps 1 and 2. 



3. 



4. 
5. 
6. 



After the completion of the procedure, the S-CSCF sends Accounting-Request with Accounting- 
Record-Type indicating EVENT_RECORD to record transaction specific information in the 
S-CSCF CDR. 

The CCF acknowledges the reception of the data and produces an S-CSCF CDR. 
Same as 3, but for P-CSCF. 
Same as 4, creating a P-CSCF CDR. 
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5.1.2.1.3 



PSTN Related Procedures 



5.1.2.1.3.1 



Session Establishment - PSTN Initiated 



Figure 5.7 shows the Diameter transactions that are required between MGCF and CCF during session establishment 
initiated from the PSTN side. 



PSTN 



l.IAM 



4. ANM 



Home Network 



MGCF 



CCF 

(home) 



2. INVITE 



More SIP/ISUP signalling 



3. 200 OK (Invite) 



5. Accounting Request [Start] 



Open a MGCF CDR 



6. Accounting Answer 



More SIP signalling 



Session established 



Figure 5.7: Message Sequence Chart for Session Establishment (PSTN Initiated) 

1 . The session is originated from the PSTN. 

2. The session setup is triggered in the IMS. 

3. The destination party answers and a final response is received. 

4. MGCF forwards an answer message to the PSTN. 

5. Upon reception of the final response, the MGCF sends an Accounting-Request with 

Accounting-Record-Type indicating START_RECORD to record start of a user session and start of a media component 
in the MGCF CDR. 

6. The CCF acknowledges the reception of the data and opens a MGCF CDR. 
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5.1.2.1.3.2 



Session Establishment - IMS Initiated 



Figure 5.8 shows the Diameter transactions that are required between BGCF, MGCP and CCF during session 
estabUshment initiated from the IMS side. 



Home Network 




Figure 5.8: Message Sequence Chart for Session Establishment (IMS Initiated) 



1. 

2. 
3. 
4. 
5. 



6. 

7. 



The session is originated from the IMS. 

A session towards PSTN is established. 

The destination party answers and an answer message is received. 

A final response message is sent to the session originator. 

Upon reception of the answer message, the MGCF sends an Accounting-Request with 

Accounting-Record-Type indicating START_RECORD to record start of a user session and start of 

a media component in the MGCF CDR. 

The CCF acknowledges the reception of the data and opens a MGCF CDR. 

Upon reception of the 200 OK message, the BGCF sends an Accounting-Request with 

Accounting-Record-Type indicating START_RECORD to record start of a user session and start of 

a media component in the BGCF CDR. 

The CCF acknowledges the reception of the data and opens a BGCF CDR. 
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5.1.2.1.3.3 



Session Release - PSTN Initiated 



Figure 5.9 shows the Diameter transactions that are required between BGCF, MGCP and CCF during a PSTN initiated 
session release. The BGCF is only involved if the session had been initiated from the IMS side. 



Home Network 



BGCF 



2. BYE 



MGCF 



CCF 



Session ongoing 



2. BYE 



6. Accounting Request [St( 



7. Accounting Answer 



l.REL 



3.RLC 



4. Accounting Request [Stop] 



PSTN 



Close the MGCF CDR 



^ 



Accounting Answer 



)P] 



Close BGCF CDR 



Figure 5.9: Message Sequence Chart for Session Release (PSTN initiated) 



1. 

2. 
3. 
4. 



5. 
6. 

7. 



The session release is initiated from PSTN. 

Session release continues within IMS. 

The reception of the release message is acknowledged. 

Upon reception of the release message, the MGCF sends an Accounting-Request with 

Accounting-Record-Type indicating STOP_RECORD to record stop of a session in the MGCF 

CDR. 

The CCF acknowledges the reception of the data and closes the MGCF CDR. 

Same as 4, but for BGCF. 

Same as 5, but for BGCF. 
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5.1.2.1.3.4 



Session Release - IMS Initiated 



Figure 5.10 shows the Diameter transactions that are required between BGCF, MGCP and CCF during a IMS initiated 
session release. 

The BGCF is only involved if the session had been initiated from the IMS side. 

Home Network 



BGCF 



MGCF 



CCF 



Session ongoing 



l.BYE 



l.BYE 



4. Accounting Request [Sti 



'P] 



I J. Accounting Answer 



2. REL 



3.RLC 



Close BGCF CDR 



6. Accounting Request [Stop] 



Close the MGCF CDR 



7. Accounting Answer 



PSTN 



Figure 5.10: Message Sequence Chart for Session Release (IMS initiated) 



1. 

2. 
3. 
4. 



5. 
6. 

7. 



The session release is initiated from the IMS side. 

A release message is sent towards PSTN. 

The acknowledgement of the release message is received from PSTN. 

Upon reception of the BYE message, the BGCF sends an Accounting-Request with 

Accounting-Record-Type indicating STOP_RECORD to record stop of a session in the BGCF 

CDR. 

The CCF acknowledges the reception of the data and closes the BGCF CDR. 

Same as 4, but for MGCF. 

Same as 5, but for MGCF. 



5.1.2.1.4 



MRFC Related Procedures 



5.1.2.1.4.1 



Multi-Party Call 



Figure 5. 11 shows the establishment of an ad hoc conference (multiparty call). An AS (acting as B2BUA) performs 
third party call control with the MRFC, where the S-CSCF is in the signalling path. The Application Server that is in 
control of the ad hoc conference is aware of the MRFC capabilities. 

NOTE: Only accounting information sent from the MRFC is shown in detail in the figure. The SIP messages are 
for illustrative purpose only. 
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UE-1 



AS 



S-CSCF 



1. INVITE (MPTY) 



CCF 



^ . INVITE (MPTY ) 



Service Logic 



MRFC 



2. INVITE (UE-2 S^P) 2. INVITE (UE-2 SDP) 



3. ^0OK(UE-2SD ^ ) 3. 200 OK (UE-2 SDP) 



UE-2 



4. A ccounting request [Start] 



Open MRFCCDR 



6. INVITE (UE-2 S^P) 

7. ^0OK(UE-2SD ^ ) 



5. A ccounting Answer 

6. INVITE (UE-2 SDP) 



7. 200 OK (UE-2 SDP) 



8. ACK(UE-2SDP ^^ 8. ACK (UE-2 SDP) 



9. Accounting request [Interim] 



Update MRFC CDR 



11 . ACK (UE-2 SD^) 



10. Accounting Answe r 
11. ACK (UE-2 SDP) 



12 . INVITE (UE-3 ^DP) 12. INVITE (UE-3 SDP) 



13 .200OK(UE-3SDP ) 13. 200 OK (UE-3 SDP) 



14. INVITE (UE-3 SDP) 



14. INVITE (UE-3 SDP) 



15 . 200 OK (UE-3 S[^) 

16 . ACK (UE-3 SDP) 16. ACK (UE-3 SDP) 



15. 200 OK (UE-3 SDP) 



17. Accounting request [Interim] 



JZ 



Update MRFC CDR 



18. Accounting Answer 
►, 



19 . ACK(UE-3SD l P) 

i ^1 



19. ACK (UE-3 SDP) 



20 . INVITE (UE-1 §DP) 

i ^1 



20. INVITE (UE-1 SDP) 



21 .200 OK (UE-1 S[ j P) 21 . 200 OK (UE-1 SDP) 



22 .200OK(MPT^ 



23. 200 OK (MPTY) 



24 . ACK (UE-1 SD^) 24. ACK (UE-1 SDP) 




25. Accounting request [Interim] 



Update MRFC CDR 



26. A ccounting Answe r 



UE-3 




Figure 5.11 : Message Sequence Chart for Multi-Party Call Establishment in MRFC 
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I. Sessions exist between UE-1 and UE-2, and between UE-1 and UE-3. A request is received from 
UE-lfor putting all parties together to a multi-party call. 

2-3. Request and acknowledgement to initiate a multi-party call. MRFC assigns a conference-ID that is 

used by the AS in subsequent interactions with the MRFC in INVITE messages connecting other 
endpoints (see TS 23.228 [18]). Path estabHshment between AS and MRFC for UE-2. 

4. At start of session establishment the MRFC sends an Accounting-Request with Accounting- 
Record-Type indicating START_RECORD to record start of a multi-party call in the MRFC CDR. 

5. The CCF acknowledges the reception of the data and creates the MRFC CDR. 'Calling Party 
Address', 'Service Request Time Stamp', 'Service ID' (holding the conference-ID) etc. are included 
in the MRFC CDR 

6-7. Path establishment between UE-2 and AS. Same ICID is used as for the path between AS and 

MRFC for UE-2 (step 2. - 3.). 

8. Acknowledgement of path between AS and MRFC for UE-2. 

9. The MRFC may send an Accounting-Request with Accounting-Record-Type indicating 
INTERIM_RECORD to report that UE-2 has been connected to the multi-party call. 

10. The CCF acknowledges the reception of the data and includes UE-2 in the field 'Application 
Provided Called Parties' of the MRFC CDR. 

I I . Acknowledgement of path between AS and UE-2. 

Now a path between UE-2 and MRFP via AS is established 
12 - 13. Request and acknowledgement to establish path between AS and MRFC for UE-3. 

14 - 15. Path establishment between UE-3 and AS. Same ICID is used as for the path between AS and 

MRFC for UE-3 (step 12. - 13.). 

16. Acknowledgement of path between AS and MRFC for UE-3. 

17. The MRFC may send an Accounting-Request with Accounting-Record-Type indicating 
INTERIM_RECORD to report that UE-3 has been connected to the multi-party call. 

18. The CCF acknowledges the reception of the data and includes UE-3 in a new field 'Application 
Provided Called Parties' of the MRFC CDR. 

19. Acknowledgement of path between AS and UE-3. 

Now a path between UE-3 and MRFP via AS is established. 
20-21. Request and acknowledgement to establish path between AS and MRFC for UE-1. Same ICID is 

used as for the path between UE-1 and AS (step 1.). 
22-23. Request for multi -party conference with UE-2 and UE-3 is acknowledged to UE-1. 

Implicit acknowledgement of path UE-1 to AS. 

24. Acknowledgement of path between AS and MRFC for UE-1. 
Now a path between UE-1 and MRFP via AS is established 

25. The MRFC may send an Accounting-Request with Accounting-Record-Type indicating 
INTERIM_RECORD to report that UE-1 has been connected to the multi -party call. 

26. The CCF acknowledges the reception of the data and includes the field 'Service Delivery Start 
Time Stamp' into the MRFC CDR. 

27 - 28. UE-1 acknowledges the multi -party call session establishment. 

NOTE: It is in the responsibility of the AS to terminate the sessions existing at the beginning of the multi -party 
call establishment between UE-1 and UE-2 and between UE-1 and UE-3 (see step 1.) in case of 
successful multi -party call establishment. This is not shown in figure 5.11. 
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5.1.2.1.5 



AS Related Procedures 



Application servers may support a multitude of services which are not specified in 3GPP standards. Therefore it is not 
possible to standardise charging flows and procedures for those services. However, for all such services, the AS may 
apply either Event Charging, where ACR [Event] messages are generated, or Session Charging, using ACR [Start, Stop 
and Interim]. The following subclauses depict one example for each of the two scenarios. The first procedure, AS acting 
as a Redirect Server, depicts the "event" case, while the second procedure, AS acting as a Voice Mail Server, depicts the 
"session" case. 



5.1.2.1.5.1 



AS Acting as a Redirect Server 



Figure 5.12 shows the case where an Application Server acts as a Redirect Server. In the figure below, UE-1 sets up a 
session towards UE-2 but due to Call Forwarding functionality located in the AS, a new number (to UE-3) is returned to 
UE-1. Finally UE-1 sets up the session towards UE-3. 



Originating UE-l 
home network 



Terminating UE-2 Home Network 



Terminating UE-3 
liome network 



S-CSCF 



1. INVITE 



AS 



Service control 



6. 302 MOVED TEMPOR ^RILY 



7. ACK 



. INVITE 



1. INVITE 



CCF 

(home) 



Application performs 
number translation 



2. 302 MOVED TEMPORARILY 



3. ACK 



4. Accounting Request [Eve it] 



Create an AS CDR 



5. Accounting Answer 



Setting up session towards UE-3 



Figure 5.12: Message Sequence Chart for AS Acting as a Redirect Server 



1. 

2.- 
4. 



3. 



5. 

6-7. 



Sessions initiated by UE-1 towards UE-2. 

Response indicating that session should be redirected towards another number (UE-3). 

After successful service execution, the AS sends Accounting-Request with 

Accounting-Record-Type indicating EVENT_RECORD to record service specific information in 

the AS CDR. 

The CCF acknowledges the reception of the data and creates the AS CDR. 

Response indicating that session should be redirected towards another number (UE-3). 

Session is initiated by UE-1 towards UE-3. 
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5.1.2.1.5.2 



AS Acting as a Voice Mail Server 



Figure 5.13 shows the case where an AppHcation Server acts as a Voice Mail Server. S-CSCF invokes the AS acting as 
Voice Mail Server according to procedure as defined in TS 23.218 [5]. 



S-CSCF 



AS (Voice 
Mail) 



CCF 



SIP signalling 



1. Invite 



Voice mail service invoked. 



2. 200 OK (Invite) 



3. Accounting Request [Start] 



Open an AS CDR 



4. Accounting Answer 



Voice mail session (playing announcements, etc.). . . When voice mail ends, tearing down session 



5. BYE 



6. Accounting Request [Step] 



Close the AS CDR 



7. Accounting Answer 



Figure 5.13: Message Sequence Chart for AS Acting as a lUlail Server 



1. 

2. 

3. 

4. 

5. 
6. 

7. 



AS receives the INVITE from the S-CSCF. 

AS acknowledges the initiated Voice Mail session by issuing a 200 OK in response to the 
INVITE. 

AS sends Accounting-Request with Accounting-Record-Type indicating START_RECORD to 
record start of a voice mail session. 

The CCF acknowledges the reception of the Accounting-Request with Accounting-Record-Type 
indicating START_RECORD and opens a AS CDR. 
Voice mail session release is initiated. 

Upon reception of release message AS sends an Accounting-Request with Accounting-Record- 
Type indicating STOP_RECORD to record stop of a session in the AS CDR. 
The CCF acknowledges the reception of the data and closes the AS CDR. 



£75/ 



3GPP TS 32.225 version 5.4.0 Release 5 27 ETSI TS 1 32 225 V5.4.0 (2003-1 2) 

5.1 .2.2 Message Flows - Error Cases and Scenarios 

This subclause describes various error cases and how these should be handled. The error cases are grouped into the 
following categories: 

• Failure in SIP Related Procedures; 

Session Related Error Scenarios; 
Session Unrelated Error Scenarios. 

• Errors in Diameter (Accounting) Related Procedures. 

5.1 .2.2.1 Error Cases - Session Related SIP Procedures 

5.1 .2.2.1 .1 Reception of SIP error messages 

A SIP session is closed abnormally by the reception of a BYE message indicating the reason for such termination. 
In this case, an ACR [Stop] message that includes an appropriate error indication is sent. 

5.1.2.2.1.2 SIP session failure 

All nodes involved in the SIP session are expected to exercise some kind of session supervision. In case a node detects 
an error in the SIP session, such as a timeout or the occurrence of an invalid SIP message that results in the inability to 
maintain the session, this IMS node will generate a BYE message towards both ends of the connection. 

The node that sent the BYE to trigger session termination identifies the cause of the failure in the ACR [Stop] towards 
the CCF. All other nodes, i.e. those that receive the BYE, are not aware of an error, and therefore they treat this 
situation as any normal SIP session termination. 

5.1 .2.2.2 Error Cases - Session Unrelated SIP procedures 

As described in subclause 5. 1 .2. 1 .2, a session unrelated SIP procedure may either be completed with the reception of a 
200OK, or a SIP error message. If the latter occurs, i.e. there is a failure in the procedure, the ACR [Event] sent towards 
the CCF includes an appropriate error indication. 

5.1 .2.2.3 Error Cases - Diameter procedures 

5.1 .2.2.3.1 CCF Connection Failure 

When the connection towards the primary CCF is broken, the process of sending accounting information should 
continue towards a secondary CCF (if such a CCF is configured). For further CCF connection failure functionality, see 
subclause "Transport Failure Detection" in [3]. 

If no CCF is reachable the network element may buffer the generated accounting data in non- volatile memory. Once the 
CCF connection is working again, all accounting messages stored in the buffer is sent to the CCF, in the order they were 
stored in the buffer. 

5.1 .2.2.3.2 No Reply from CCF 

In case an IMS node does not receive an ACA in reply to an ACR, it may repeat the ACR message. The waiting time 
until a repetition is sent, and the maximum number of repetitions are both configurable by the operator. When the 
maximum number of repetitions is reached and still no ACA reply has been received, the IMS node executes the CCF 
connection failure procedure as specified above. 

If retransmitted ACRs are sent, they are marked with the T-flag as described in [3] , in order to allow duplicate 
detection in the CCF, as specified in the next subclause. 
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5.1.2.2.3.3 



Duplicate Detection 



A Diameter client marks possible duplicate request messages (e.g. retransmission due to the link failover process) with 
the T-flag as described in [3]. 

If the CCF receives a message that is marked as retransmitted and this message was already received, then it discards 
the duplicate message. However, if the original of the re-transmitted message was not yet received, it is the information 
in the marked message that is taken into account when generating the CDR. The CDRs are marked if information from 
duplicated message(s) is used. 



5.1.2.2.3.4 



CCF Detected Failure 



The CCF closes a CDR when it detects that expected Diameter ACRs for a particular SIP session have not been 
received for a period of time. The exact behaviour of the CCF is operator configurable. 



5.1.3 Message Formats 



5.1.3.1 



Summary of Offline Charging Message Formats 



The IMS nodes generate accounting information that can be transferred from the nodes to the CCF. For this purpose, the 
IMS Charging application employs the Accounting-Request and Accounting-Answer messages from the base Diameter 
protocol. 

Table 5.3 describes the use of these messages for offline charging. 

Table 5.3: Offline Charging Messages Reference Table 



Command-Name 


Source 


Destination 


Abbreviation 


Accounting-Request 


S-CSCF, l-CSCF, P-CSCF, MRFC, 
MGCF, BGCF, AS 


CCF 


AGR 


Accounting-Answer 


CCF 


S-GSGF, l-GSGF, P-GSGF, MRFG, 
MGGF, BGGF, AS 


AGA 



5.1.3.2 



Structure for the Accounting Message Formats 



The following is the basic structure shared by all offline charging messages. This is based directly on the format of the 
Accounting-Request and Accounting-Answer messages defined in the base Diameter protocol specification [3]. Detailed 
description of the AVPs and their use for offline and online charging are provided in clause 7. 

Those Diameter AVPs that are used for offline charging are marked "Yes" in tables 5.4 to 5.7. Those Diameter AVPs 
that are not used for offline charging are marked "No" in tables 5.4 to 5.7. This implies that their content can (Yes) or 
can not (No) be used by the CCF to construct CDRs. 

The following symbols (adopted from [3]) are used in the tables: 

• <AVP> indicates a mandatory AVP with a fixed position in the message. 

• {AVP} indicates a mandatory AVP in the message. 

• [AVP] indicates an optional AVP in the message. 

• *AVP indicates that multiple occurrences of an AVP are possible. 
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5.1.3.2.1 



Accounting-Request Message 



Table 5.4 illustrates the basic structure of a Diameter Accounting-Request message as used for offline charging. The use 
of the AVPs is specified in subclause 5.1.3.3 per IMS node and ACR type. 

Table 5.4: Accounting-Request (ACR) Message Contents for Offline Charging 



Diameter base protocol AVPs 


AVP 


Used in offline ACR 


<Diameter-Header:271 ,REQ,PXY> 


Yes 


<Session-ld> -- Diameter Session Id 


Yes 


{Origin-Host} 


Yes 


{Origin-Realm} 


Yes 


{Destination-Realm} 


Yes 


{Accou nting- Record-Type} 


Yes 


{Accounting-Record-Number} 


Yes 


[Acct-Application-ld] 


No 


[Vendor-Specific-Application-ld] 


Yes 


[User-Name] 


Yes 


[Accounting-Sub-Session-Id] 


No 


[Accounting-RADIUS-Session-ld] 


No 


[Acct-Multi-Session-ld] 


No 


[Acct-lnterim-lnterval] 


Yes 


[Accounting-Realtime-Required] 


No 


[Origin-State-Id] 


Yes 


[Event-Timestamp] 


Yes 


*[Proxy-lnfo] 


No 


*[Route-Record] 


No 


*[AVP] 


No 


Diameter Credit Control AVP 


[Subscription-Id] 


No 


[Requested-Action] 


No 


*[Requested-Service-Unit] 


No 


*[Used-Service-Unit] 


No 


*[Service-Parameter-lnfo] 


No 


[Abnormal-Termination-Reason] 


No 


*[Accounting-Correlation-ld] 


No 


[Credit-Control-Failure-Handling] 


No 


[Direct-Debiting-Failure-Handling] 


No 


3GPP Diameter accounting AVPs 


[Event-Type] 


Yes 


[Role-of-node] 


Yes 


[User-Session-ID ] 


Yes 


[Calling-Party-Address] 


Yes 


[Called-Party-Address] 


Yes 


[Time-stamps] 


Yes 


'[Application-Server] 


Only for S-CSCF 


*[Application-provided-Called-Party-Address] 


Only for S-CSCF 


*[lnter-Operator-ldentifier] 


Yes 


[IMS-Charging-ldentifier] 


Yes 


*[SDP-Session-Description] 


Yes 


*[SDP-Media-Component] 


Yes 


[GGSN-Addressl 


Yes 


[Served- Party- 1 P-Address] 


Only for P-CSCF 


[Authorised-QoS] 


Only for P-CSCF 


[Server-Capabilities] 


Only for l-CSCF 


[Trunk-Group-ID] 


Only for MGCF 


[Bearer-Service] 


Only for MGCF 


[Service-ID] 


Only for MRFC 


[UUS-Data] 


Yes 


[Cause] 


Yes 



NOTE: For AVP of type "Grouped" only the group AVP is listed in table 5.4. Detailed descriptions of the AVPs 
is provided in clause 7. 
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5.1.3.2.2 



Accounting-Answer Message 



Table 5.5 illustrates the basic structure of a Diameter Accounting-Answer message as used for IMS charging. This 
message is always used by the CCF as specified below, regardless of the IMS node it is received from and the ACR 
record type that is being replied to. 

Table 5.5: Accounting-Answer (ACA) Message Contents for Offline Charging 



Diameter base protocol AVPs 


AVP 


Used in Offline ACA 


<Diameter-Header:271 ,PXY> 


Yes 


<Session-ld> 


Yes 


{Result-Code} 


Yes 


{Origin-Host} 


Yes 


{Origin-Realm} 


Yes 


{Accounting-Record-Type} 


Yes 


{Accounting-Record-Number} 


Yes 


[Acct-Application-ld] 


No 


[Vendor-Specific-Application-Id] 


Yes 


[User-Name] 


Yes 


[Accounting-Sub-Session-ld] 


No 


[Accounting-RADIUS-Session-ld] 


No 


[Acct-Multi-Session-ld] 


No 


[Error-Reporting-Host] 


No 


[Acct-lnterim-lnterval] 


Yes 


[Accounting-Realtime-Required] 


No 


[Origin-State-Id] 


Yes 


[Event-Timestamp] 


Yes 


*[Proxy-lnfo] 


No 


*[AVP] 


No 



5.1.3.3 Detailed Message Formats 

Following the base protocol specification, the following "types" of accounting data may be sent: 

• Start session accounting data. 

• Interim session accounting data. 

• Stop session accounting data. 

• Event accounting data. 

ACR types Start, Interim and Stop are used for accounting data related to successful SIP sessions. In contrast. Event 
accounting data is unrelated accounting data, such as a simple registration or interrogation and successful service event 
triggered by an AS. In addition. Event accounting data are also used for unsuccessful SIP session establishment 
attempts. 

The following table specifies per ACR type the accounting data that are sent by each of the IMS network elements: 

S-CSCF 

P-CSCF 

I-CSCF 

MRFC 

MGCF 

BGCF 

AS 
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The ACR types in the table are listed in the following order: S (start)/! (interim)/S (stop)/E (event). Therefore, when all 
ACR types are possible it is marked as SISE. If only some ACR types are allowed for a node, only the appropriate 
letters are used (i.e. SIS or E) as indicated in the table heading. The omission of an ACR type for a particular AVP is 
marked with "-" (i.e. SI-E). Also, when an entire AVP is not allowed in a node the entire cell is marked as "-". 

Note that not for all Grouped AVPs the individual AVP members are listed in the table. See clause 7 for a detailed list 
of the AVP group members and for the description of the AVPs. 

For the ACA the same details listed in table 5.8 applies with the addition that Error-Reporting-Host AVP is supported 
in all ACAs in a similar manner as most other base protocol AVPs (e.g. in the same manner as Origin-State-Id AVP). 

Table 5.8: Detailed Diameter ACR Message Contents for Offline Charging 



AVP name 


Node Type 


S-CSCF 


P-CSCF 


l-CSCF 


MRFC 


MGCF 


BGCF 


AS 


Supported ACRs 


S/l/S/E 


S/l/S/E 


E 


S/l/S 


S/l/S/E 


S/l/S/E 


S/l/S/E 


AVPs from the Diameter base protocol 


<Session-ld> 


SISE 


SISE 


E 


SIS 


SISE 


SISE 


SISE 


{Origin-Host} 


SISE 


SISE 


E 


SIS 


SISE 


SISE 


SISE 


{Origin-Realm} 


SISE 


SISE 


E 


SIS 


SISE 


SISE 


SISE 


{Destination-Realm} 


SISE 


SISE 


E 


SIS 


SISE 


SISE 


SISE 


{Accounting-Record-Type} 


SISE 


SISE 


E 


SIS 


SISE 


SISE 


SISE 


{Accounting-Record-Number} 


SISE 


SISE 


E 


SIS 


SISE 


SISE 


SISE 


[Vendor-Specific-Application-ld] 


SISE 


SISE 


E 


SIS 


SISE 


SISE 


SISE 


[Acct-Application-ld] 




- 


- 


- 


- 


- 


- 


[User-Name] (see note 1) 


SISE 


SISE 


E 


SIS 


SISE 


SISE 


SISE 


[Accounting-Sub-Session-Id] 


- 


- 


- 


- 


- 


- 


- 


[Accounting-RADIUS-Session-ld] 


- 


- 


- 


- 


- 


- 


- 


[Acct-Multi-Session-ld] 




- 


- 


- 


- 


- 


- 


[Acct-lnterim-lnterval] 


SIS- 


SIS- 


- 


SIS- 


SIS- 


SIS- 


SIS- 


[Accounting-Realtime-Required] 


- 


- 


- 


- 


- 


- 


- 


[Origin-State-Id] 


SISE 


SISE 


E 


SIS 


SISE 


SISE 


SISE 


[Event-Timestamp] 


SISE 


SISE 


E 


SIS 


SISE 


SISE 


SISE 


*[Proxy-lnfo] 




- 


- 


- 


- 


- 


- 


*[Route-Record] 




- 


- 


- 


- 


- 


- 


*[AVP] 


- 


- 


- 


- 


- 


- 


- 


Diameter Credit Control AVP 


[Subscription-Id] 


- 


- 


- 


- 


- 


- 


- 


[Requested-Action] 




- 


- 


- 


- 


- 


- 


*[Requested-Service-Unit] 




- 


- 


- 


- 


- 


- 


*[Used-Service-Unit] 


- 


- 


- 


- 


- 


- 


- 


*[Service-Parameter-lnfo] 


- 


- 


- 


- 


- 


- 


- 


[Abnormal-Termination-Reason] 


- 


- 


- 


- 


- 


- 


- 


*[Accounting-Correlation-ld] 




- 


- 


- 


- 


- 


- 


[Credit-Control-Failure-Handling] 




- 


- 


- 


- 


- 


- 


[Direct-Debiting-Failure-Handling] 


- 


- 


- 


- 


- 


- 


- 


3GPP Diameter accounting AVPs 


[Event-Type] 


SISE 


SISE 


E 


SIS 


SISE 


SISE 


SISE 


[Role-of-Node] 


SISE 


SISE 


E 


SIS 


SISE 


SISE 


SISE 


[User-Session-Id] 


SISE 


SISE 


E 


SIS 


SISE 


SISE 


SISE 


[Calling-Party-Address] 


SISE 


SISE 


E 


SIS 


SISE 


SISE 


SISE 


[Called-Party-Address] 


SISE 


SISE 


E 


SIS 


SISE 


SISE 


SISE 


[Time-stamps] 


SISE 


SISE 


E 


SIS 


SISE 


SISE 


SISE 


•[Application-server] (see note 1) 


SISE 


- 


- 


SIS 


- 


- 


- 


*[Application-Provided-Called-Party-Address] (see note 1) 


SISE 


- 


- 


SIS 


- 


- 


- 


[Inter-Operator-Identifiers] 
(see note 1 ) 


SISE 


SISE 


E 


SIS 


SISE 


SISE 


SISE 


[IMS-Charging-ldentifier] 


SISE 


SISE 


E 


SIS 


SISE 


SISE 


SISE 


*[SDP-Session-Description] 
(see note 2) 


SI-E 


SI-E 


- 


Sl- 


SI-E 


SI-E 


SI-E 


*[SDP-Media-component] 
(see note 2) 


SI-E 


SI-E 




Sl- 


SI-E 


SI-E 


SI-E 


[GGSN-Address] 


SI-E 


SI-E 




Sl- 


SI-E 


SI-E 


SI-E 


[Served-Party-IP-Address] 
(see note 1 ) 


- 


SISE 


- 


- 


- 


- 


- 
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AVP name 


Node Type 


S-CSCF 


P-CSCF 


l-CSCF 


MRFC 


MGCF 


BGCF 


AS 


Supported ACRs 


S/l/S/E 


S/l/S/E 


E 


S/l/S 


S/l/S/E 


S/l/S/E 


S/l/S/E 


[Authorized-QoS] (see note 1 ) 


- 


SISE 


- 


- 


- 


- 


- 


[Server-Capabilities] 




- 


E 


- 


- 


- 


- 


[Trunl<-Group-ID] 




- 


- 


- 


SISE 


- 


- 


[Bearer-Service] 


- 


- 


- 


- 


SISE 


- 


- 


[Service-Id] 


- 


- 


- 


SIS 


- 


- 


- 


[UUS-Data] (see note 3) 


SISE 


SISE 










SISE 


[Cause] 


-SE 


-SE 


E 


-s 


-SE 


-SE 


-SE 


NOTE 1 : Only present if available in the IMS node. 

NOTE 2: Present in Interim and Event ACRs only if the SIP transactions that triggered the ACR contained SDP. 

NOTE 3: Present only if user-to-user data is included in the SIP message that triggered the ACR. 



5.2 CDR Description on the Bi Interface 
5.2.1 CDR Field Types 

The following Standard CDR content and format are considered; 

S-CSCF-CDR generated based on information from the S-CSCF. 

I-CSCF-CDR generated based on information from the I-CSCF. 

P-CSCF-CDR generated based on information from the P-CSCF. 

BGCF-CDR generated based on information from the BGCF. 

MGCF-CDR generated based on information from the MGCF. 

MRFC-CDR generated based on information from the MRFC. 

AS-CDR generated based on information from the AS. 

The content of each CDR type is defined in Table 5.9 . For each CDR type the field definition includes the field name 
and category. The field descriptions are provided in clause 5.2.4. 

Equipment vendors shall be able to provide all of the fields listed in the CDR content table in order to claim compliance 
with the present document. However, since CDR processing and transport consume network resources, operators may 
opt to eliminate some of the fields that are not essential for their operation. This operator provisionable reduction is 
specified by the field category. 

A field category can have one of two primary values: 

M This field is Mandatory and shall always be present in the CDR. 

C This field shall be present in the CDR only when certain Conditions are met. These Conditions are specified as 
part of the field definition. 

Some of these fields are designated as Operator provisionable. Using TMN management functions or specific tools 
provided by an equipment vendor, operators may choose if they wish to include or omit the field from the CDR. Once 
omitted, this field is not generated in a CDR. To avoid any potential ambiguity, a CDR generating element MUST be 
able to provide all these fields. Only an operator can choose whether or not these fields should be generated in their 

system. 

Those fields that the operator may configure to be present or absent are further qualified with the "Operator 
provisionable" subscript as follows: 

Mo This is a field that, if provisioned by the operator to be present, shall always be included in the CDRs. In other 
words, an M^ parameter that is provisioned to be present is a mandatory parameter. 

Co This is a field that, if provisioned by the operator to be present, shall be included in the CDRs when the 
required conditions are met. In other words, a Co parameter that is configured to be present is a conditional 
parameter. 
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The CCF provides the CDRs at the Bi interface in the format and encoding described in the present document. 
Additional CDR formats and contents may be available at the interface to the billing system to meet the requirements of 
the billing system, these are outside of the scope of 3GPP standardisation. 

5.2.2 CDR Triggers 

5.2.2.1 Session Related CDRs 

Reflecting the usage of multimedia sessions IMS CDRs are generated by the CCF on a per session level. In the scope of 
the present document the term "session" refers always to a SIP session. The coherent media components are reflected 
inside the session CDRs with a media component container comprising of all the information necessary for the 
description of a media component. 

Accounting information for SIP sessions is transferred from the IMS nodes involved in the session to the CCF using 
Diameter ACR Start, Interim and Stop messages. A session CDR is opened in the CCF upon reception of a Diameter 
ACR [Start] message. Partial CDRs may be generated upon reception of a Diameter ACR [Interim] message which is 
sent by the network entity towards the CCF due to a session modification procedure (i.e. change in media). Session 
CDRs are updated, or partial CDRs are generated upon reception of a diameter ACR [Interim] message which is sent by 
the network entity due to expiration of the Accounting-Interim-Interval AVP. The CCF closes the final session CDR 
upon reception of a Diameter ACR [Stop] message, which indicates that the SIP session is terminated. Further details 
on triggers for the generation of IMS CDRs are specified in [2] . 

Accounting information for unsuccessful session set-up attempts may be sent by the IMS node to the CCF employing 
the Diameter ACR [Event] message. The behaviour of the CCF upon receiving ACR [Event] messages is specified in 

subclause 5.2.2.2. 

5.2.2.2 Session Unrelated CDRs 

To reflect chargeable events not directly related to a session the CCF may generate CDRs upon the occurrence of 
session unrelated SIP procedures, such as registration respectively de-registration events. Accounting information for 
SIP session-unrelated procedures is transferred from the IMS nodes involved in the procedure to the CCF using 
Diameter ACR [Event] messages. Session unrelated CDRs are created in the CCF in a "one-off" action based on the 
information contained in the Diameter ACR [Event] message. One session unrelated CDR is created in the CCF for 
each Diameter ACR [Event] message received, whereas the creation of partial CDRs is not applicable for session 
unrelated CDRs. The cases for which the IMS nodes send ACR [Event] messages are listed per SIP procedure in 
tables 5.1 and 5.2. 

Further details on triggers for the generation of IMS CDRs are specified in [2] . 
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5.2.3 CDR Content 

Table 5.9 specifies the content of each CDR type. For each column describing the CDR type, the field name and its 
category are specified. The detailed description of the field is provided in section 5.2.1. Diagonal shading of a cell 
indicates, that the particular CDR field is not included in the particular CDR type. 

Table 5.9: Charging Data of IMS CDR Types 



Field 



S-CSCF- 
CDR 



P-CSCF- 
CDR 



l-CSCF- 
CDR 



CDR Type 



MRFC-CDR 



MGCF-CDR 



BGCF-CDR 



AS-CDR 



Record Type 



M 



M 



M 



M 



M 



M 



Retransmission 



Co 



Co 



Co 



Co 



Co 



Co 



Co 



SIP IVIethod 



Co 



Co 



Co 



Co 



Co 



Co 



Co 



Role of Node 



Mo 



Mo 



Mo 



Mo 



Mo 



Node Address 



Mo 



Mo 



Mo 



Mo 



Mo 



Session ID 



Mo 



Mo 



Mo 



Mo 



Mo 



Service ID 



Mo 



Calling Party Address 



Mo 



Mo 



Mo 



Mo 



Mo 



Called Party Address 




Service Request Time Stamp 



Service Delivery Start Time Stamp 



Mo 



Mo 




Mo 



Mo 



Service Delivery End Time Stamp 



Co 



Co 



Co 



Co 



Co 



Record Opening Time 



Co 



Co 



Co 



Co 



Co 



Record Closure Time 



Mo 



Mo 



Mo 



Mo 



Application Servers Information 



Co 



Co 



Application Servers Involved 



Co 



Application Provided Called 
Parties 



Co 



Inter Operator Identifiers 



Co 



Co 



Co 



Co 



Co 



Co 



Co 



originating 101 



Co 



Co 



Co 



Co 



Co 



Co 



Co 



terminating 101 



Co 



Co 



Co 



Co 



Co 



Co 



Co 



Local Record Sequence Number 



Mo 



Mo 



Mo 



Mo 



Mo 



Record Sequence Number 



Co 



Co 



Co 



Co 



Co 



Cause For Record Closing 



Mo 



Mo 



Mo 



Mo 



Mo 



Incomplete CDR Indication 



Co 



Co 



Co 



Co 



Co 



Co 



Co 



S-CSCF Information 



Co 



IMS Charging Identifier 



Mo 



Mo 



Mo 



Mo 



Mo 



SDP Session Description 



Co 



Co 




Co 



Co 



Co 



Co 



List of SDP Media Components 



Co 



Co 



Co 



Co 



Co 



SIP Request Timestamp 



Mo 



Mo 



Mo 



Mo 



SIP Response Timestamp 



Mo 



Mo 




Mo 



Mo 



SDP Media Components 



Mo 



Mo 



Mo 



Mo 



SDP Media Name 



Mo 



Mo 



Mo 



Mo 



SDP Media Description 



Mo 



Mo 




Mo 



Mo 



GPRS Chiarging ID 



Mo 



Mo 



Mo 



Mo 



Media Initiator Flag 



GGSN Address 



Co 



Co 



Co 



Co 



Co 



Co 



Co 



Co 



Co 



Co 



Co 



Co 



Co 



Service Delivery Failure Reason 




Trunk Group ID Incoming/Outgoing 



Bearer Service 



Record Extensions 



Co 
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5.2.4 CDR Parameter Description 

This clause contains a brief description of each field of the CDRs described in Table 5.9. The fields are listed in 
alphabetical order according to the field name as specified in the table above. 

5.2.4.1 Application Provided Called Parties 

Holds a list of the Called Party Address(es), if the address(es) are determined by an AS (SIP URL, E.164...). 

5.2.4.2 Application Servers Information 

This a grouped CDR field containing the fields; "Application Server Involved" and "Application Provided Called 
Parties". 

5.2.4.3 Application Servers Involved 

Holds the ASs (if any) identified by the SIP URLs. 

5.2.4.4 Authorised QoS 

Authorised QoS as defined in TS 23.207 [7] / TS 29.207 [8] and applied via the Go interface. 

5.2.4.5 Bearer Service 

Holds the used bearer service for the PSTN leg. 

5.2.4.6 Called Party Address 

In the context of an end-to-end SIP transaction this field holds the address of the party (Public User ID) to whom the 
SIP transaction is posted. 

For a subscription/registration procedure this field holds the party to be registered/subscribed. 

This field contains either a SIP URL (according to IETF RFC3261 [16]) or a TEL URL (according to RFC2806 [20]). 

5.2.4.7 Calling Party Address 

The address (Public User ID) of the party requesting a service or initiating a session. This field holds either the SIP 
URL (according to IETF RFC 3261 [16]) or the TEL URL (according to RFC 2806 [20]) of the calling party. 

5.2.4.8 Cause for Record Closing 

This field contains a reason for the release of the CDR including the following: 

normal release: end of session; 

partial record generation: time (duration) limit, maximum number of changes in charging conditions (e.g. 
maximum number in List of Message Bodies' exceeded) or service change (e.g. change in media components); 

abnormal termination; 

management intervention (request due to O&M reasons). 

CCF initiated record closure; 

A more detailed reason may be found in the Service Delivery Failure Reason field. 
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5.2.4.9 Content Disposition 

This sub-field of Message Bodies holds the content disposition of the message body inside the SIP signalling, Content- 
disposition header field equal to "render", indicates that "the body part should be displayed or otherwise rendered to the 
user". Content disposition values are: session, render, inline, icon, alert, attachment, etc. 

5.2.4.10 Content Length 

This sub-field of Message Bodies holds the size of the data of a message body in bytes. 

5.2.4.11 Content Type 

This sub-field of Message Bodies holds the MIME type of the message body. Examples are: application/zip, image/gif, 
audio/mpeg, etc. 

5.2.4.12 GGSN Address 

This parameter holds the control plane IP address of the GGSN that handles one or more media component(s) of a IMS 
session. If GPRS is used to access the IMS, the GGSN address is used together with the GPRS charging ID as the 
access part of the charging correlation vector. The charging correlation vector is comprised of an access part and an 
IMS part, which is the IMS Charging Identifier. For further information regarding the composition of the charging 
correlation vector refer to the appropriate clause in TS 32.200 [2]. 

5.2.4.13 GPRS Charging ID 

This parameter holds the GPRS charging ID (GCID) which is generated by the GGSN for a GPRS PDP context. There 
is a 1:1 relationship between the GCID and the PDP context. If GPRS is used to access the IMS, the GCID is used 
together with the GGSN address as the access part of the charging correlation vector that is comprised of an access part 
and an IMS part, which is the IMS Charging Identifier. 

For further information regarding the composition of the charging correlation vector refer to the appropriate clause in 
TS 32.200 [2]. 

5.2.4.14 IMS Charging Identifier 

This parameter holds the IMS charging identifier (ICID) as generated by the IMS node for the SIP session. The value of 
the ICID parameter is identical with the 'icid-value' parameter defined in [15]. The 'icid-value' is a mandatory part of the 
P-Charging- Vector and coded as a text-based UTF-8 charset (as are all SIP messages). For further information 
regarding the composition and usage of the P-Charging- Vector refer to TS 32.200 [2], TS 24.229 [14] and [15]. 

The ICID value is globally unique across all 3GPP IMS networks for a time period of at least one month, implying that 
neither the node that generated this ICID nor any other IMS node reuse this value before the uniqueness period expires. 
The one month minimum uniqueness period counts from the time of release of the ICID, i.e. the ICID value no longer 
being used. This can be achieved by using node specific information, e.g. high-granularity time information and / or 
topology / location information. The exact method how to achieve the uniqueness requirement is an implementation 
issue. 

An ICID is generated by the P-CSCF during the initial IMS registration procedure for a Private User ID. At each SIP 
session unrelated method (e.g., REGISTER, NOTIFY, MESSAGE etc.), a new, session unrelated specific ICID is 
generated at the first IMS network element that processes the method. 

At each SIP session establishment a new, session specific ICID is generated at the first IMS network element that 
processes the session-initiating SIP INVITE message. This ICID is then used in all subsequent SIP messages for that 
session (e.g., 200 OK, (re-)INVITE, BYE etc.) until the session is terminated. 

5.2.4.15 Incomplete CDR Indication 

This field provides additional diagnostics when the CCF detects missing ACRs. 
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5.2.4.1 6 Inter Operator Identifiers 

Holds the identification of the home network (originating and terminating) if exchanged via SIP signalhng, as recorded 
in the Inter-Operator-Identifier AVP. For further information on the lOI please refer to TS 24.229 [14]. 

5.2.4.17 List of Message Bodies 

This grouped field comprising several sub-fields describing the data that may be conveyed end-to-end in the body of a 
SIP message. Since several message bodies may be exchanged via SIP-signalling, this grouped field may occur several 
times. 

The List of Message Bodies contains the following elements: 

■ Content Type 

■ Content Disposition 

■ Content Length 

■ Originator 

They are described in the appropriate subclause. Message bodies with the "Content-Type" field set to application/sdp 
and the "Content-Disposition" field set to session are not included in the "Message Bodies" field. 

5.2.4.1 8 List of SDP Media Components 

This is a grouped field comprising several sub-fields associated with one media component. It may occur several times 
in one CDR. The field is present only in a SIP session related case. 

The List of SDP Media Components contains following elements: 

■ SIP Request Timestamp 

■ SIP Response Timestamp 

■ SDP Media Components 

■ Media Initiator flag 

These field elements are described in the appropriate subclause. 

5.2.4.19 Local Record Sequence Number 

This field includes a unique record number created by this node. The number is allocated sequentially for each partial 
CDR (or whole CDR) including all CDR types. The number is unique within the CCF. 

The field can be used e.g. to identify missing records in post processing system. 

5.2.4.20 Media Initiator Flag 

This field indicates if the called party has requested the session modification and it is present only if the initiator was the 
called party. 

5.2.4.21 Node Address 

This item holds the address of the node providing the information for the CDR. This may either be the IP address or the 
FQDN of the IMS node generating the accounting data. This parameter corresponds to the Origin-Host AVP. 

5.2.4.22 Originator 

This sub-field of the "List of Message Bodies" indicates the originating party of the message body. 
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5.2.4.23 Private User ID 

Holds the used Network Access Identifier of the served party according to RFC2486 [6]. This parameter corresponds to 
the User-Name AVP. 

5.2.4.24 Record Closure Time 

A Time stamp reflecting the time the CCF closed the record. 

5.2.4.25 Record Extensions 

A set of operator/manufacturer specific extensions to the record, conditioned upon existence of an extension. 

5.2.4.26 Record Opening Time 

A time stamp reflecting the time the CCF opened this record. Present only in SIP session related case. 

5.2.4.27 Record Sequence Number 

This field contains a running sequence number employed to link the partial records generated by the CCF for a 
particular session (characterised with the same Charging ID and GGSN address pair). The Record Sequence Number is 
not present if the record is the only one produced in the CCF for a session. The Record Sequence Number starts from 
one (1). 

5.2.4.28 Record Type 

Identifies the type of record. The parameter is derived from the Origin-Host AVP. 

5.2.4.29 Retransmission 

This parameter, when present, indicates that information from retransmitted Diameter ACRs has been used in this CDR. 

5.2.4.30 Role of Node 

This fields indicates the role of the AS/CSCF. As specified in TS 23.218 [5] the role can be: 

• originating (CSCF serving the calling subscriber or AS irutiated session) 

• terminating (CSCF serving the called subscriber or AS terminated session) 

• proxy (only applicable for an AS, when a request is proxied) 

• B2BUA (only applicable for an AS, when the AS performs third party control/acts in B2BUA mode. 

5.2.4.31 SDP Media Components 

This is a grouped field comprising several sub-fields associated with one media component. Since several media 
components may exist for a session in parallel these sub-fields may occur several times (as much times as media are 
involved in the session). The sub-fields are present if medium (media) is (are) available in the SDP data which is 
provided in the ACR received from the IMS node. 

The SDP media component contains the following elements: 

■ SDP media name 

■ SDP media description 

■ GPRS Charging ID 

These field elements are described in the appropriate subclause. 

5.2.4.32 SDP Media Description: 

This field holds the attributes of the media as available in the SDP data tagged with "i=", "c=","b=","k=", "a=". Only 
the attribute lines relevant for charging are recorded. To be recorded "SDP lines" shall be recorded in separate "SDP 
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Media Description" fields, thus multiple occurrence of this field is possible. Always complete "SDP lines" are recorded 
per field. 

This field corresponds to the SDP -Media-Description AVP as defined in Table 5.8. 

Example: "c=IN IP4 134.134.157.81" 

For further information on SDP please refer to IETF draft 'SDP.Session Description Protocol' [17]. 

Note: session unrelated procedures typically do not contain SDP data. 

5.2.4.33 SDP Media Name 

This field holds the name of the media as available in the SDP data tagged with "m=". Always the complete "SDP line" 
is recorded. 

This field corresponds to the SDP -Media-Name AVP as defined in Table 5.8. 

Example: "m=video 51372 RTP/AVP 31" 

For further information on SDP please refer to IETF draft 'SDP: Session Description Protocol' [17]. 

5.2.4.34 SDP Session Description 

Holds the Session portion of the SDP data exchanged between the User Agents if available in the SIP transaction. 

This field holds the attributes of the media as available in the session related part of the SDP data tagged with "c=" and 
"a=" (multiple occurrence possible). Only attribute lines relevant for charging are recorded. 

The content of this field corresponds to the SDP-Session-Description AVP of the ACR message. 

Note: session unrelated procedures typically do not contain SDP data. 

5.2.4.35 Service Delivery End Time Stamp 

This field records the time at which the service delivery was terminated. It is Present only in SIP session related case. 

The content of this field corresponds to the SIP-Request-Timestamp AVP of a received ACR[Stop] message indicating a 
session termination. 

5.2.4.36 Service Delivery Failure Reason 

Holds the reason for why a requested service could not be successfully provided (i.e. SIP error codes taken from SIP- 
Method AVP). This field is not present in case of a successful service delivery. 

5.2.4.37 Service Delivery Start Time Stamp 

This field holds the time stamp reflecting either: 

a successful session set-up: this field holds the start time of a service delivery (session related service) 
a delivery of a session unrelated service: the service delivery time stamp 

an unsuccessful session set-up and an unsuccessful session unrelated request: this field holds the time the network 
entity forwards the unsuccessful indication (SIP "RESPONSE" with error codes 3xx, 4xx, 5xx) towards the 
requesting User direction. 
The content of this field corresponds to the SIP-Response-Timestamp AVP as defined in Table 5.8. 

For partial CDRs this field remains unchanged. 

5.2.4.38 Service ID 

This field identifies the service the MRFC is hosting. For conferences the conference ID is used here. 
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5.2.4.39 Service Request Timestamp 

This field contains the time stamp which indicates the time at which the service was requested ("SIP request" message) 
and is present for session related and session unrelated procedures. The content of this item is derived from the SIP- 
Request-Timestamp AVP as defined in Table 5.8. If the SIP-Request-Timestamp AVP is not supplied by the 
network entity this field is not present. 

For partial CDRs this field remains unchanged. 

This field is present for unsuccessful service requests if the ACR message includes the SIP-Request-Timestamp AVP. 

5.2.4.40 Service Specific Data 

This field contains service specific data. 

5.2.4.41 Session ID 

The Session identification. For a SIP session the Session-ID contains the SIP Call ID as defined in the Session Initiation 
Protocol RFC [16]. 

5.2.4.42 Served Party IP Address 

This field contains the IP address of either the calling or called party, depending on whether the P-CSCF is in touch 
with the calling or called network. 

5.2.4.43 SIP Method 

Specifies the SIP-method for which the CDR is generated. Only available in session unrelated cases. 

5.2.4.44 SIP Request Timestamp 

This parameter contains the time of the SIP Request (usually a (Re)Invite). 

5.2.4.45 SIP Response Timestamp 

This parameter contains the time of the response to the SIP Request (usually a 200 OK). 

5.2.4.46 S-CSCF Information 

This field contains Information related to the serving CSCF, e.g. the S-CSCF capabilities upon registration event or the 
S-CSCF address upon the session establishment event. This field is derived from the Server-Capabilities AVP if present 
in the ACR received from the I-CSCF. 

5.2.4.47 Trunk Group ID Incoming/Outgoing 

Contains the outgoing trunk group ID for an outgoing session/call or the incoming trunk group ID for an incoming 
session/call. 

5.2.5 Bi interface Conventions 

The present document gives several recommendations for the main protocol layers for the Bi interface protocol stack. 
These recommendations are not strictly specified features, since there are a lot of variations among the existing Billing 
Systems. 

As a minimum, all implementations shall support a file based bulk interface for the transfer of CDRs from the CCF to 
the BS. The recommendation is FTP over TCP/IP. 
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5.2.6 Abstract Syntax Description 



TS32225-DataTypes (42} — to be allocated, value "42" is used to allow compilation of the code 

DEFINITIONS IMPLICIT TAGS ::= 

BEGIN 

— Exports everything 

IMPORTS 

TimeStamp 

FROM TS32205-DataTypes { itu-t (0) identif ied-organization (4) etsi(O) mobileDomain (0) 

umts-Operation-Maintenance (3) ts-32-205 (205) InformationModel (0) asnlModule (2) versionl (1) 



IMSRecord 



SET 



Fields used by several multimedia Record types ("Common fields") ; 
(which field is used in which record type is defined in section 5.2.3) 



recordType [0] 

retransmission [1] 

sIP-Method [2] 

role-of-Node [3] 

nodeAddress [4] 

session-Id [5] 

calling-Party-Address [6] 

called-Party-Address [7] 

privateUserlD [8] 

serviceRequestTimeStamp [9] 

serviceDe livery St art Time St amp [10] 

serviceDeliveryEndTimeStamp [11] 

recordOpeningTime [12] 

recordClosureTime [13] 

interOperatorldentif iers [14] 

localRecordSequenceNumber [15] 

recordSequenceNumber [16] 

causeForRecordClosing [17] 

incomplete-CDR-Indication [18] 

iMS-Charging-Identifier [19] 

sDP-Session-Description [20] 

list-Of-SDP-Media-Components [21] 

gCSNaddress [22] 

serviceDeliveryFailureReason [23 ] 

list-Of-Message-Bodies [24] 

recordExtensions [25] 

— Space left for further "common fields" 



Cal IE vent RecordType, 

NULL OPTIONAL, 

SIP-Method OPTIONAL, 

Role-of-Node OPTIONAL, 

NodeAddress OPTIONAL, 

Session-Id OPTIONAL, 

InvolvedParty OPTIONAL, 

InvolvedParty OPTIONAL, 

GraphicString OPTIONAL, 

TimeStamp OPTIONAL, 
TimeStamp OPTIONAL, 
TimeStamp OPTIONAL, 
TimeStamp OPTIONAL, 
TimeStamp OPTIONAL, 
InterOperat or Identif iers OPTIONAL, 
LocalRecordSequenceNumber OPTIONAL, 
INTEGER OPTIONAL, 

CauseForRecordClosing OPTIONAL, 
Incomplete-CDR-Indication OPTIONAL 
IMS-Charging-Identifier OPTIONAL, 
SEQUENCE OF Graphic STRING OPTIONAL, 
SEQUENCE OF Media-Components-List OPTIONAL, 
NodeAddress OPTIONAL, 

ServiceDeliveryFailureReason OPTIONAL, 
SEQUENCE OF MessageBody OPTIONAL, 
RecordExtensions OPTIONAL, 



— Fields particular used in the S-CSCF-recordType : 
applicationServersInformation [40] SEQUENCE OF ApplicationServersInf ormation OPTIONAL, 

— Fields particular used in the P-CSCF-recordType : 
servedPartylPAress [50] ServedPartylPAddress OPTIONAL, 

— < ServedPartylPAddress to be defined > 

— Fields particular used in the I-CSCF-recordType : 
transactionTimestamp [60] TimeStamp OPTIONAL, 
s-CSCF-Information [61] S-CSCF-Inf ormation OPTIONAL, 

— < S-CSCF-Information to be defined > 

— Fields particular used in the MRFC-recordType : 
service-Id [70] Service-Id OPTIONAL, 

— <Service-Id to be defined> 

— Fields particular used in the MGCF-recordType : 
trunlcGroupID [80] TrunlcGroupID OPTIONAL, 
bearerService [81] TransmissionMedium OPTIONAL, 

— Fields particular used in the BGCF-RecordType (start with tag 90) : 

— <empty so far> 

— Fields particular used in the AS-RecordType : 
serviceSpecificData [100] OCTET STRING OPTIONAL 
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ACRInterimLost 



ENUMERATED 



no (0), 
yes (1) , 
unknown (2) 



ApplicationServers Information 



SEQUENCE 



{ 



applicationServersInvolved [0] NodeAddress OPTIONAL, 
applicationProvidedCalledParties [1] SEQUENCE OF InvolvedParty OPTIONAL 



CauseForRecordClosing 
{ 



ENUMERATED 



serviceDeliveryEndSuccess fully 

unSuccessfulServiceDelivery 

timeLimit 

serviceChange 

management Intervention 



(0) 
(1) 
(3) 
(4) 
(5) 



e.g. change in media due to Re-Invite 
partial record generation reasons to be added 



Additional codes are for further study 



IMS-Charging-Identifier ::= OCTET STRING 



I ncomplete-CDR- Indication 



SET 



aCRStartLost [0] BOOLEAN, — TRUE if ACR[Start] was lost, FALSE otherwise 

aCRInterimLost [1] ACRInterimLost, 

aCRStopLost [2] BOOLEAN — TRUE if ACR[Stopl was lost, FALSE otherwise 



Inter Operator Identifiers 
{ 



SEQUENCE 



originatinglOI [0] GraphicString OPTIONAL, 
terminatinglOI [1] GraphicString OPTIONAL 



InvolvedParty 
{ 



CHOICE 



sIP-URL [0] GraphicString, 
tEL-URL [1] GraphicString 



-- refer to rfc3261 
-- refer to rfc3261 



IPAddress 



CHOICE 



ipV4Addr [0] GraphicString, - 
ipV6Addr [1] GraphicString - 



- "dot" notation is used 

- "dot" notation is used 



LocalRecordSequenceNumber ::= INTEGER (0 .. +2147483647 ) 

— A unique number assigned by the CCF and supplied to all CDRs . The value range 

— limits the field to a maximum 4 octet INTEGER. 

Media-Components-List ::= SEQUENCE 
{ 

sIP-Request-Timestamp [0] TimeStamp OPTIONAL, 

sIP-Response-Timestamp [1] TimeStamp OPTIONAL, 

sDP-Media-Components [2] SDP-Media-Components OPTIONAL, 

medialnitiatorFlag [3] NULL OPTIONAL, 

authorized-QoS [3] GraphicString OPTIONAL 



MessageBody 



SEQUENCE 



Content-Type 
Content -Disposition 
Content -Length 
Originator 



[0] GraphicString OPTIONAL, 

[1] GraphicString OPTIONAL, 

[2] INTEGER OPTIONAL, 

[3] InvolvedParty OPTIONAL 



NodeAddress 



CHOICE 



IPAddress [0] IPAddress, 
domainName [1] GraphicString 
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RecordExtensions ::= SEQUENCE 



operator specific record extensions 



Role-of-Node ::= ENUMERATED 
{ 

originating (0), 

terminating (1), 

proxy (2) , 

b2bua (3) 
} 

SDP-Media-Components ::= SEQUENCE 

{ 

sDP-Media-Name [0] SEQUENCE OF GraphicString OPTIONAL, 

SDP-Media-Descriptions [1] SEQUENCE OF SDP-Media-Description OPTIONAL, 
gPRS-Charging-Id [2] INTEGER OPTIONAL, 

) 

SDP-Media-Description ::= SEQUENCE OF GraphicString OPTIONAL, 

ServiceDeliveryFailureReason ;;= GraphicString 

— holds the SIP error code as received via a SIP Final response (4xx, 5xx or 6xx) 

Session-Id ;;= GraphicString 

— rfc3261: example for SIP Call-ID: f81d4fae-7dec-lld0-a765-00a0c91e6bf6@foo.bar.com 

Sip-Method ::= GraphicString 

TransmissionMedium ::= SEQUENCE { 

— Transmission Medium Required, refer to ITU-T Q.763: 
tMR [0] OCTET STRING (SIZE (1)) OPTIONAL, 

— Transmission Medium USED, refer to ITU-T Q.763: 
tMU [1] OCTET STRING (SIZE (1)) OPTIONAL 

} 

TrunkGroupID ::= CHOICE { 

incoming [0] GraphicString, 

outgoing [1] GraphicString 
} 

END 
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5.2.7 Data Encoding Rules 

Data encoding rules are descried in [9] for BER, in [10] for PER, or in [11] for XER. 

6 Online Charging 

6.1 Diameter Description on the Ro Interface 

6.1.1 Basic Principles 

IMS online charging essentially uses the same protocol that is used for offline charging. However, for online charging 
the protocol may include additional Attribute-Value Pairs (AVPs) within the existing messages. 

Two cases for online event charging are distinguished: 

• Immediate Event Charging (lEC); and 

• Event Charging with Unit Reservation (ECUR). 

In the case of Immediate Event Charging (lEC), granting units to the AS is performed in a single operation that also 
includes the deduction of the corresponding monetary units from the subscriber's account. The charging process is 
controlled by the coiiesponding Accounting-Record-Type EVENT_RECORD which is sent with an ACR for a given 
accounting event. 

In contrast. Event Charging with Unit Reservation (ECUR) also includes the process of requesting, reserving, releasing 
and returning unused units. The deduction of the corresponding monetary units then occurs upon conclusion of the 
ECUR transaction. In this case, the Accounting-Record-Type START / INTERIM / STOP_RECORD are used to control 
the accounting session. During a SIP session there can be repeated execution of unit reservation and debit operations as 
specified in TS 32.200 [2]. 

The AS/MRFC may apply either lEC, where ACR Event messages are generated, or ECUR, using ACR Start, Stop and 
Interim. The decision whether to apply lEC or ECUR is based on the service and/or operator's policy. 

NOTE: To the extent possible alignment with the IETF Credit Control Application, [13], is planned. However, 
this can only be accomplished when the current IETF draft receives an official RFC status. 

6.1 .2 Message Flows and Types 

This subclause describes the message flows for the event charging procedures on the Ro interface. 

6.1 .2.1 Immediate Event Charging (lEC) 

This subclause provides the details of the "Debit Units" operation specified in TS 32.200 [2]. 
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6.1.2.1.1 



Message Flows - Successful Cases and Scenarios 



6.1.2.1.1.1 



lEC - Debit Units Operation 



Figure 6. 1 shows the transactions that are required on the Ro interface in order to perform lEC with Debit Units 
operations. The Debit Units operation may ahernatively be carried out prior to, concurrently with or after 
service/content dehvery. The AS/MRFC must ensure that the requested service execution is successful, when this 
scenario is used. 




Figure 6.1 : lEC - Debit Units Operation 

The AS/MRFC receives a SIP related service request from S-CSCF. 



2. 



3. 

4. 
5. 



The Debit Units Operation is performed as described in TS 32.200 [2]. 

The AS/MRFC performs lEC prior to service execution. AS/MRFC sends Accounting-Request 

(ACR) with Accounting-Record-Type AVPset to EVENT_RECORD to indicate service specific 

information to the ECF. The Requested-Action AVP (RA) is set to DIRECT_DEBITING. If 

known, the AS/MRFC may include Requested-Service-Unit AVP (RSU) (monetary or non 

monetary units) in the request message. 

Having transmitted the Accounting-Request message the AS/MRFC starts the communication 

supervision timer Tx [13]. Upon receipt of the Accounting Answer (ACA) message the AS/MRFC 

shall stop timer Tx. 

The ECF determines the relevant service charging parameters in conjunction with the other 

internal charging functions of the OCS. 

The ECF returns Accounting- Answer message W\\h Accounting-Record-Type AVP set to 

EVENT_RECORD to the AS/MRFC in order to authorize the service execution 

(Granted-Service-Unit AVP (GSU) and possibly Cost-Information AVP (CI) indicating the cost of 

the service are included in the Accounting-Answer message). The Accounting-Answer message has 

to be checked by the AS/MRFC accordingly and the requested service is controlled concurrently 

with service delivery. 

Service is being delivered. 
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6.1 .2.1 .2 Message Flows - Error Cases and Scenarios 

This subclause describes various error cases and how these should be handled. 

The failure handling behaviour is locally configurable in the AS/MRFC. If the Direct-Debiting-Failure-Handling AVP 
is not used, the locally configured values are used instead. 

6.1 .2.1 .2.1 Reception of SIP Error Messages 

If SIP errors occur during service delivery, as defined in [5] and [12], it is up to the AS/MRFC to determine to what 
extent the service was delivered before the error occurred and act appropriately with respect to charging. This may 
imply that no units at all (or no more units) are debited. 

6.1 .2.1 .2.2 Debit Units Operation Failure 

This case comprises situations where either no, or an erroneous response, is received from the ECF. The "no response" 
case is detected by the AS/MRFC when the connection supervision timer Tx expires [13] before a response AccoMnftn^- 
Answer ( ACA) is received. The case of receiving an erroneous response implies that the AS/MRFC receives an 
Accounting-Answer (ACA), which it is unable to process, while Tx is running. The failure handling complies with the 
failure procedures for "Direct Debiting" scenario described in [13]. 

6.1.2.1.2.3 Duplicate Detection 

The detection of duplicate request is needed and must be enabled. To speed up and simplify as much as possible the 
duplicate detection, the all-against-all record checking should be avoided and just those records marked as potential 
duplicates need to be checked against other received requests (within a reasonable time window) by the receiver entity. 

The AS/MRFC mark the request messages that are retransmitted after a link failover as possible duplicates with the T- 
flag as described in [3]. For optimized performance, uniqueness checking against other received requests is only 
necessary for those records marked with the T-flag received within a reasonable time window. This focused check is 
based on the inspection of the Session-Id and Accounting-Record-Number AVP pairs. 

Note that for lEC the duplicate detection is performed in the Correlation Function that is part of the OCS. The ECF that 
receives the possible duplicate request should mark as possible duplicate the corresponding request that is sent over the 
Re interface. 

6.1 .2.2 Event Charging with Unit Reservation (ECUR) 

This subclause provides the details of the "Reserve Units" and "Debit Units" operations specified in TS 32.200 [2]. 



£75/ 



3GPP TS 32.225 version 5.4.0 Release 5 



47 



ETSI TS 132 225 V5.4.0 (2003-12) 



6.1.2.2.1 



Message Flows - Successful Cases and Scenarios 



6.1.2.2.1.1 



ECUR - Reserve Units and Debit Units Operations 



Figure 6.2 shows the transactions that are required on the Ro interface in order to perform ECUR with Reserve Units 
and Debit Units operations. Multiple replications of both of these operations are possible. 



1. Service Request 



5. Service Delivery 



9. Service Delivery 



Reserve Units Operation 

2. ACR (START_RECORD, RSU, [AH]) 



3. Perform Event 
Charging Control 



4. ACA (START_RECORD, GSU, [All]) 



Reserve Units and Debit Units Operations 

6. ACR (INTERIM_RECORD, RSU, USU) 



7. Perform Event Charging Control 



8. ACA (INTERIM_RECORD, GSU, [EUI]) 



Debit Units Operation 

10. ACR (STOP_RECORD, USU) 



1 1. Perform Event Charging Control 



12. ACA (STOP_RECORD, CI) 



Figure 6.2: ECUR - Reserve Units and Debit Units Operations 

1. The AS/MRFC receives a SIP related service request from S-CSCF. The service request may be 

initiated by either the user or an AS/MRFC. 

The Reserve Units Operation is performed as described in TS 32.200 [2]. 



2. 



3. 



5. 



In order to perform Reserve Units operation for a number of units (monetary or non-monetary 
units), the AS/MRFC sends an ACR W\\h Accounting-Record-Type AVP set to START_RECORD 
to the ECF. If known, the AS/MRFC may include Requested-Service-Unit (RSU) AVP (monetary 
or non monetary units) and Acc-Interim-Interval (All) AVP in the request message. 
If the service cost information is not received by the ECF, the ECF determines the price of the 
desired service according to the service specific information received by issuing a rating request to 
the Rating Function. If the cost of the service is included in the request, the ECF directly reserves 
the specified monetary amount. If the credit balance is sufficient, the ECF reserves the 
corresponding amount from the users account. 

Once the reservation has been made, the ECF returns Accounting-Answer message with 
Accounting-Record-Type set to START_RECORD to the AS/MRFC in order to authorize the 
service execution (Granted-Service-Unit and possibly Cost-Information indicating the cost of the 
service are included in the Accounting-Answer message). If requested, the ECF returns the Acc- 
Interim-Interval (All) AVP with value field set to a non-zero value. 
Content/service delivery starts and the reserved units are concurrently controlled. 
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The Reserve Units and Debit Units Operations are performed as described in TS 32.200 [2]. 

6. During content/service delivery, in order to perform Debit Units and subsequent Reserve Units 
operations, the AS/MRFC sends an ACR with Accounting-Record-Type AVP set to 
INTERIM_RECORD, to report the units used and request additional units, respectively. The ACR 
message with Accounting-Record-Type AVP set to INTERIM_RECORD must be sent by the 
AS/MRFC between the START_RECORD and STOP_RECORD either on request of the credit 
control application within the interim interval or if the interim interval is elapsed. If known, the 
AS/MRFC may include Requested-Service-Unit AVP (monetary or non monetary units) in the 
request message. The Used-Service-Unit (USU) AVP is complemented in the ACR message to 
deduct units from both the user's account and the reserved units, respectively. 

7. The ECF deducts the amount used from the account. If the service cost information is not received 
by the ECF, the ECF determines the price of the desired service according to the service specific 
information received by issuing a rating request to the Rating Function. If the cost of the service is 
included in the request, the ECF directly reserves the specified monetary amount. If the credit 
balance is sufficient, the ECF reserves the corresponding amount from the users account. 

8. Once the deduction and reservation have been made, the ECF returns Accounting- Answer message 
with Accounting-Record-Type set to INTERIM_RECORD to the AS/MRFC, in order to allow the 
content/service delivery to continue (new Granted-Service-Unit (GSU) AVP and possibly Cost- 
Information (CI) AVP indicating the cumulative cost of the service are included in the Accounting- 
Answer message). The ECF may include in the ACA message the Final-Unit-Indication (FUI) 
AVP to indicate the final granted units. 

9. Content/service delivery continues and the reserved units are concurrently controlled. 

The Debit Units Operation is performed as described in TS 32.200 [2]. 

10. When content/service delivery is completed or the final granted units have been consumed, the 
AS/MRFC sends AC/? with Accounting-Record-Type AVP set to STOP_RECORD to terminate 
the active accounting session and report the used units. 

1 1 . The ECF deducts the amount used from the account. Unused reserved units are released, if 
applicable. 

12. The ECF acknowledges the reception of the ACR message by sending ACA message with 
Accounting-Record-Type AVP indicating STOP_RECORD (possibly Cost-Information AVP 
indicating the cumulative cost of the service is included in the. Accounting-Answer message). 

NOTE: The ECUR scenario is supervised by corresponding timers (e.g. accounting interval timer) that are not 
shown in the figure 6.2. 

6.1 .2.2.1 .2 Support of Tariff Switch 

Changes to the tariffs pertaining to the service may be handled in the following ways. 

• Tariff Changes handled using Acct-Interim-Interval AVP; or 

• Tariff changes handled using the Tariff Switch Time AVP. 

6.1 .2.2.1 .2.1 Tariff CInanges Inandled using Acct-Interim-Interval AVP 

The tariff change for online charging can be achieved by setting the value of the Acct-Interim-Interval AVP (ECF 
controlled) in a manner that it matches the desired tariff switch time. 

6.1 .2.2.1 .2.2 Tariff changes handled using the Tariff Switch Time AVP 

To indicate a change of tariff to the AS/MRFC, the ECF can include the Tariff Switch Time {Tariff-Switch-Definition 
AVP), i.e. a timer value referring to the change of tariff, in the Accounting-Answer. The Tariff Switch Time is evaluated 
by the AS/MRFC relative to the time stamp of the Accounting-Request {Accounting-Record-Type START_RECORD or 
INTERIM_RECORD). By that it is possible to eliminate any delays of the signalling between AS/MRFC and ECF. 

Together with the Tariff Switch Time the ECF also provides the granted service units. These units can be provided in 
one portion or in two, referring to the granted service units before and after the tariff switch. 
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If a Tariff Switch Time is received, the AS/MRFC starts the tariff switch timer and use the granted service units for 
usage metering. If both, granted service units before and after the tariff switch have been provided, the AS/MRFC uses 
the units granted before the tariff switch (pre-switch quota). 

If the pre-switch quota is exhausted, the AS/MRFC sends an Accounting-Request to the ECF. The Accounting-Request 
contains the amount of service units used from the beginning of the connection only. The value of the tariff switch timer 
is discarded in the AS/MRFC and it is the responsibility of the ECF to provide a new Tariff Switch Time in the 
Accounting-Answer. 

If the tariff switch timer expired, the AS/MRFC further continues usage metering using the post-switch quota, if 
provided, but no Accounting-Request is sent. If no specific units were granted to after tariff switch time, the AS/MRFC 
continues usage metering with the remaining units granted. 

If the post switch quota is exhausted, the AS/MRFC sends an Accounting-Request to the ECF, containing the service 
units used before the last tariff switch, the service units used after the last tariff switch and the tariff switch time. 

If the granted units - provided in one portion - are exhausted, an Accounting-Request is sent. If a tariff switch has 
occurred in this time, the Accounting-Request contains the service units used before the tariff switch, the service units 
used after the tariff switch and the time of the tariff switch. Otherwise, if no tariff switch has occurred, the 
Accounting-Request contains the overall amount of used service units. 

There may be some AS/MRFCs that do no support tariff switching. In this case, the AS/MRFC ignores the AVPs 
associated with this feature (i.e. Tariff-Switch-Definition and Unit-Value-After-Tariff-Switch AVPs). The 
Granted-Service-Unit, Unit-Value and Used-Service-Unit AVPs are treated as if the Tariff Switch feature does not exist. 

Figure 6.3 shows the messages exchanged on the Ro interface for ECUR for a tariff change. This scenario covers a 
tariff switch where the granted service units are provided in two portions, before and after the tariff switch. No 
additional Accounting-Request takes place, as the granted service units were not exhausted. 
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5. ACA (STOP_Record, Debit Units Res.) 



Figure 6.3: Tariff Chiange in thie AS/IVIRFC 



3. 
4. 

5. 



In order to perform credit control with reservation of an amount of units (monetary or 

non-monetary units) the AS/MRFC sends an ACR with Accounting-Record-Type set to 

START_RECORD to ECF. The Requested-Action is set to RESERVE_UNITS. 

Once the reservation has been made, ECF returns an ACA with Accounting-Record-Type set to 

START_RECORD to the AS/MRFC in order to authorize the content/service deUvery. The ACA 

includes the Tariff Switch Time, the service units granted before the tariff switch and the service 

units granted after the tariff switch. 

Upon receipt of the ACA, the AS/MRFC evaluates the tariff switch time relative to the timestamp 

of the ACR, starts the tariff switch timer and monitors service usage based on the service units 

granted before the tariff switch. 

The Tariff Switch Timer expires. The AS/MRFC now monitors service usage based on the service 

units granted after the tariff switch. 

The AS/MRFC sends ACR with Accounting-Record-Type set to STOP_RECORD to terminate the 

active accounting session. The message includes the amount of service units used before the tariff 

switch, the amount of service units used after the tariff switch and the time of the tariff change. 

An Accounting-Answer is sent from the ECF back to the AS/MRFC as an acknowledgment of the 

successful debit process and to finalize the transaction. 
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6.1 .2.2.1 .3 Expiration of Reservation Validity 

This subclause defines how reserved units are returned, if not used, within a reasonable time. It should be possible that 
both the reservation and SIP sessions are cancelled or only the reservation is cancelled without removing the SIP 
session. Work on this is ongoing in IETF Credit Control Draft [13]. Alignment with [13] is planned. 

6.1 .2.2.2 Message Flows - Error Cases and Scenarios 

This subclause describes various error cases and how these should be handled. 

The failure handling behaviour is locally configurable in the AS/MRFC. If Credit-Control-Failure-Handling AVP is 
not used, the locally configured values are used instead. 

6.1 .2.2.2.1 Reception of SIP Error Messages 

If SIP errors occur during service delivery, as defined in [5] and [12], it is up to the AS/MRFC to determine to what 
extent the service was delivered before the error occurred and act appropriately with respect to charging. This may 
imply that no units at all (or no more units) are reserved or debited. 

6.1.2.2.2.2 Reserve Units and Debit Units Operation Failure 

This case comprises of ECF connection failure, and/or receiving error responses from the ECF. 

The AS/MRFC detects an ECF connection failure when the timer Tx expires [13] or a transport failure is detected as 
defined in [3]. The ECF also has the capability to detect failures when the timer Ts [3] expires. The ECF should indicate 
the cause of failure by setting the appropriate result code as defined in [3] and [13]. In any case, the failure handling of 
AS/MRFC and ECF complies with the failure procedures for "Session Based Credit Control" scenario described in [13]. 

6.1.2.2.2.3 Duplicate Detection 

For credit control duplicate detection is performed only for possible duplicate event requests related to lEC as 
mentioned in subclause 6. 1.2. 1.2. 3, as retransmission of ECUR related accounting requests is not allowed. 

6.1.3 Message Formats 

6.1 .3.1 Summary of Online Charging Message Formats 

The existing Diameter credit control extension internet-draft [13] proposes an approach based on a series of 
"interrogations": 

• Initial interrogation (extending the start-session accounting report message). 

• Zero, one or more interim interrogations (extending the interim accounting report message). 

• Final interrogation (extending the stop-session accounting report message). 

In addition to a series of interrogations, also a one time event (interrogation) can be used e.g. in the case when service 
execution is always successful. 

All of these interrogations make use of the same Accounting-Request and Accounting-Answer messages in the base 
Diameter protocol as for the offline charging. Additional AVPs are specified for the purposes of online charging. These 
additional AVPs include all the AVPs listed in [13] and the Tariff-Switch-Definition AVP as specified in clause 7. 

The Accounting-Request for the "interim interrogation" and "final interrogation" reports the actual number of "units" 
that were used, from what was previously reserved. This determines the actual amount debited from the subscriber's 
account. 

Such an approach has the benefit of a common basic message structure, and accounting data reporting mechanism for 
both offline and online charging. 

Table 6.1 describes the use of these messages for online charging. 
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Table 6.1 : Online Charging IVIessages Reference Table 



Command-Name 


Source 


Destination 


Abbreviation 


Accounting-Request 


MRFC, AS 


ECF 


ACR 


Accounting-Answer 


ECF 


MRFC, AS 


ACA 



6.1.3.2 



Structure for the Accounting Message Formats 



The following is the basic structure shared by all online charging messages. This is based directly on the format of the 
Accounting-Request and Accounting-Answer messages defined in the base Diameter protocol specification [3] with the 
extensions defined in [13]. 

Those Diameter AVPs that are used for online charging are marked "Yes" in tables 6.2 to 6.3. Those Diameter AVPs 
that are not used for online charging are marked "No" in tables 6.2 to 6.3. This implies that their content can (Yes) or 
can not (No) be used by the ECF for charging purposes. 

The following symbols are used in the tables: 

• <AVP> indicates a mandatory AVP with a fixed position in the message. 

• {AVP} indicates a mandatory AVP in the message. 

• [AVP] indicates an optional AVP in the message. 

• *AVP indicates that multiple occurrences of an AVP is possible. 
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6.1.3.2.1 Accounting-Request Message 

Table 6.2 illustrates the basic structure of a Diameter Accounting-Request message as used for IMS online charging 
Table 6.2: Accounting-Request (ACR) Message Contents for Online Charging 



Diameter Base Protocol AVPs 


AVP 


Used In Online ACR 


<Diameter Header: 271, REQ, PXY> 


Yes 


<Session-ld> 


Yes 


{Origin-Host} 


Yes 


{Origin-Realm} 


Yes 


{Destination-Realm } 


Yes 


{Accounting-Record-Type} 


Yes 


{Accounting-Record-Number} 


Yes 


[Acct-Application-ld] 


No 


[Vendor-Specific-Application-ld] 


Yes 


[User-Name] 


Yes 


[Accounting-Sub-Session-Id] 


No 


[Accounting-RADIUS-Session-ld] 


No 


[Acct-IVIulti-Session-ld] 


No 


[Acct-lnterim-lnterval] 


Yes 


[Accounting-Realtime-Required] 


No 


[Origin-State-Id] 


Yes 


[Event-Timestamp] 


Yes 


* [Proxy- Info] 


No 


* [Route-Record] 


No 


*[AVP] 


No 


Diameter Credit Control AVPs 


[Subscription-Id] 


Yes 


[Requested-Action] 


Yes 


*[Requested-Service-Unit] 


Yes 


*[Used-Service-Unit] 


Yes 


[Tariff-Switch-Definition] 


Yes 


*[Service-Parameter-lnfo] 


Yes 


[Abnormal-Termination-Reason] 


Yes 


*[Accounting-Correlation-ld] 


No 


[Credit-Control-Failure-Handling] 


Yes 


[Direct-Debiting-Failure-Handling] 


Yes 


3GPP Diameter accounting AVPs 


[Event-Type] 


Yes 


[Role-of-node] 


Yes 


[User-Session-ID] 


Yes 


[Calling-Party-Address] 


Yes 


[Called-Party-Address] 


Yes 


[Time-stamps] 


Yes 


*[Application-Server] 


No 


*[Application-Provided-Called-Party-Address] 


Yes 


*[lnter-Operator-ldentifier] 


Yes 


[IMS-Charging-ldentifier] 


Yes 


*[SDP-Session-Description] 


Yes 


*[SDP-Media-Component] 


Yes 


[GGSN-Address] 


Yes 


[Served-Party-IP-Address] 


No 


[Authorised QoS] 


No 


[Server-Capabilities] 


No 


[Trunk-Group-ID] 


No 


[Bearer-Service] 


No 


[Service- Id] 


Yes 


[UUS-Data] 


Yes 


[Cause] 


Yes 



The detailed use of the AVPs for MRFC/AS and for each ACR record type (start/interim/stop/event) is specified in 
subclause 6.1.3.3. 
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6.1.3.2.2 



Accounting-Answer Message 



Table 6.3 illustrates the basic structure of a Diameter Accounting-Answer message as used for IMS charging. This 
message is always used by the ECF as specified below, independent of the receiving IMS node and the ACR record 
type that is being replied to. 

Table 6.3: Accounting Answer (ACA) Message Contents for Online Charging 



Diameter base protocol AVPs 


AVP 


Used in online ACA 


<Diameter Header: 271, PXY> 


Yes 


<Session-ld> 


Yes 


{Result-Code} 


Yes 


{Origin-Host} 


Yes 


{Origin-Realm} 


Yes 


{Accou nting- Record-Type} 


Yes 


{Accounting-Record-Number} 


Yes 


[Acct-Application-ld] 


No 


[Vendor-Specific-Application-ld] 


Yes 


[User-Name] 


Yes 


[Accounting-Sub-Session-Id] 


Yes 


[Accounting-RADIUS-Session-ld] 


No 


[Acct-Multi-Session-ld] 


No 


[Error-Reporting-Host] 


No 


[Acct-lnterim-lnterval] 


Yes 


[Accounting-Realtime-Required] 


No 


[Origin-State-Id] 


Yes 


[Event-Timestamp] 


Yes 


* [Proxy-Info] 


No 


*[AVP] 


No 


Diameter Credit Control AVPs 


[Subscription-Id] 


Yes 


*[Granted-Service-Unit] 


Yes 


[Tariff-Switch-Definition] 


Yes 


[Cost- Information] 


Yes 


[Final-Unit-lndication] 


Yes 


[Check-Balance-Result] 


Yes 


[Credit-Control-Failure-Handling] 


Yes 



6.1.3.3 Detailed Message Formats 

Following the protocol specifications, the following "types" of accounting data may be sent: 

• Start session accounting data. 

• Interim session accounting data. 

• Stop session accounting data. 

• Event accounting data. 

ACR types start, interim and stop are used for accounting data related to successful SIP sessions. In contrast, event 
accounting data is used for session-unrelated accounting data, such as a simple registration or interrogation, and for 
accounting data related to unsuccessful SIP session establishment attempts. 

The following table specifies per ACR type the accounting data that are sent by MRFC and AS. 

Tables 6.4 and 6.5 are the basic structure for online charging messages via Ro Interface. This is based directly on the 
Accounting-Request and Accounting-Answer messages defined in the Diameter protocol specifications [3] and [13]. 
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Table 6.4: Detailed Diameter ACR IVIessage Contents for online Charging 



AVP name 


Node Type 


MRFC 


AS 


Supported ACRs 


S/l/S/E 


S/l/S/E 


AVPs from Diameter Base Protocol 


<Session-ID> 


SISE 


SISE 


{Origin-Host} 


SISE 


SISE 


{Origin-Realm} 


SISE 


SISE 


{Destination-Realm} 


SISE 


SISE 


{Accounting-Record-Type} 


SISE 


SISE 


{Accounting-Record-Number} 


SISE 


SISE 


[Acct-Application-ID] 


- 


- 


[Vendor-Specific-Application-ID] 


SISE 


SISE 


[User-Name] 


SISE 


SISE 


[Accounting-Sub-Session-ID] 


- 


- 


[Accounting-RADIUS-Session-ID] 


- 


- 


[Acct-Multi-Session-ID] 


- 


- 


[Acct-lnterim-lnterval] 


SIS- 


SIS- 


[Accounting-Realtime-Required] 


- 


- 


[Origin-State-ID] 


SISE 


SISE 


[Event-Timestamp] 


SISE 


SISE 


*[Proxy-lnfo] 


- 


- 


*[Route-Record] 


- 


- 


*[AVP] 


- 


- 


Diameter Credit-Control AVP 


[Subscription-Id] 


SISE 


SISE 


[Requested-Action] 


SISE 


SISE 


*[Requested-Service-Unit] 


SISE 


SISE 


*[Used-Service-Unit] 


SISE 


SISE 


[Tariff-Switch-Definition] 


SISE 


SISE 


*[Service-Parameter-lnfo] 


SISE 


SISE 


[Abnormal-Termination-Reason] 


SISE 


SISE 


*[Accounting-Correlation-ld] 


SISE 


SISE 


[Credit-Control-Failure-Handling] 


SISE 


SISE 


[Direct-Debiting-Failure-Handling] 


SISE 


SISE 


*[Granted-Service-Unit] 


- 


- 


[Cost-Information] 


- 


- 


[Final-Unit-lndication] 


- 


- 


[Check-Balance-Result] 


- 


- 


3GPP Diameter Accounting AVPs 


[Event-Type] 


SISE 


SISE 


[Role-of-Node] 


SISE 


SISE 


[User-Session-ID] 


SISE 


SISE 


[Calling-Party-Address] 


SISE 


SISE 


[Called-Party-Address] 


SISE 


SISE 


[Time-stamps] 


SISE 


SISE 


[Application-server] 


- 


- 


[Application-provided-called-party-address] 


- 


- 


[Inter-Operator-Identifiers] 


SISE 


SISE 


[llVIS-Charging-ldentifierj 


SISE 


SISE 


*[SDP-Session-Description] 


Sl-E 


Sl-E 


*[SDP-Media-component] 


Sl-E 


Sl-E 


[SDP-IVIedia-Name] 


Sl-E 


Sl-E 


[GGSN-Address] 


Sl-E 


Sl-E 


GPRS-Charging-ld] 


Sl-E 


Sl-E 


[Served-Party-IP-Address] 


- 


- 


[Authorized-QoS] 


- 


- 


[Server-Capabilities] 


- 


- 


[Trunl<-Group-ID] 


- 


- 


[Bearer-Service] 


- 


- 


[Service- Id] 


SISE 




[UUS-Data] 


SISE 


SISE 


[Cause] 


-SE 


-SE 
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Table 6.5: Detailed Diameter ACA lUlessage Contents for Online Charging 



AVP name 


Node Type 


ECF 


Supported AC As 


S/l/S/E 


AVPs from Diameter Base Protocol 


<Session-ID> 


SISE 


{Result Code} 


SISE 


{Origin-Host} 


SISE 


{Origin-Realm} 


SISE 


{Accounting-Record-Type} 


SISE 


{Accounting-Record-Number} 


SISE 


[Acct-Application-ID] 


- 


[Vendor-Specific-Application-ID] 


SISE 


[User-Name] 


- 


[Accounting-Sub-Session-ID] 


- 


[Accounting-RADIUS-Session-ID] 


- 


[Acct-Multi-Session-ID] 


- 


[Error-Reporting-Host] 


- 


[Acct-lnterim-lnterval] 


SIS- 


[Accounting-Realtime-Required] 


- 


[Origin-State-ID] 


SISE 


[Event-Timestamp] 


SISE 


*[Proxy-lnfo] 


- 


"[Route-Record] 


- 


AVPs from Diameter Credit Control 


[Subscription-Id] 


SISE 


[Requested-Action] 


- 


*[Requested-Service-Unit] 


- 


*[Used-Service-Unit] 


- 


[Tariff-Switch-Definition] 


SISE 


*[Service-Parameter-lnfo] 


- 


[Abnormal-Termination-Reason] 


- 


*[Accounting-Correlation-ld] 


- 


[Credit-Control-Failure-Handling] 


- 


[Direct-Debiting-Failure-Handling] 


- 


*[Granted-Service-Unit] 


SISE 


[Cost-Information) 


SISE 


[Final-Unit-lndication] 


SISE 


[Check-Balance-Result] 


SISE 


[Credit-Control-Failure-Handling] 


SISE 
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7 



AVPs Used for Offline and Online Charging 



7.1 



Diameter Base Protocol AVPs 



The use of the Attribute Value Pairs (AVPs) that are defined in the Diameter Base Protocol [3] is specified in 
subclause 5.1.3 for offline charging and in subclause 6.1.3 for online charging. The information is summarized in table 
7.1 with the base protocol AVPs listed in alphabetical order. Detailed specification of these AVPs is available in the 
base protocol specifications. 

The 3GPP IMS Charging Application uses the value 10415 (3GPP) as Vendor-Id. 

Those Diameter AVPs that are used for IMS charging are marked "Yes" in table 7.1. Those Diameter AVPs that are not 
used for IMS charging are marked "No" in table 7.1. This implies that their content can (Yes) or can not (No) be used 
by the CCF or ECF for charging purposes. 

The following symbols (adopted from [3]) are used in the tables: 

• <AVP> indicates a mandatory AVP with a fixed position in the message. 

• {AVP} indicates a mandatory AVP in the message. 

• [AVP] indicates an optional AVP in the message. 

• *AVP indicates that multiple occurrences of an AVP are possible. 

Table 7.1 : Use Of Diameter Base Protocol AVPs in IMS 



AVP name 


Mechanism 


Offline 


Online 


Type 


ACR 


ACA 


ACR 


ACA 


Table # 


5.4 


5.5 


6.2 


6.3 


[Accounting-Multi-Session-ld] 


No 


No 


No 


No 


[Accounting-RADIUS-Session-ld] 


No 


No 


No 


No 


[Accounting-Realtime-Required] 


No 


No 


No 


No 


{Accounting-Record-Number} 


Yes 


Yes 


Yes 


Yes 


{Accounting-Record-Type} 


Yes 


Yes 


Yes 


Yes 


[Accounting-Sub-Session-ld] 


No 


No 


No 


No 


[Acct-Application-ld] 


No 


No 


No 


No 


[Acct-lnterim-lnterval] 


Yes 


Yes 


Yes 


Yes 


{Auth-Application-ld} 


- 


- 


- 


- 


<Diameter-Header:271 ,REQ,PXY> 


Yes 


Yes 


Yes 


Yes 


{Destination-Host} 


- 


- 


- 


- 


{Destination-Realm} 


Yes 


- 


Yes 


- 


[Error-IVIessage] 


- 


- 


- 


- 


[Error-Reporting-Host] 


- 


No 


- 


No 


[Event-Timestamp] 


Yes 


Yes 


Yes 


Yes 


*[Failed-AVP] 


- 


- 


- 


- 


*[Proxy-lnfo] 


No 


No 


No 


No 


{Origin-Host} 


Yes 


Yes 


Yes 


Yes 


{Origin-Realm} 


Yes 


Yes 


Yes 


Yes 


[Origin-State-Id] 


Yes 


Yes 


Yes 


Yes 


*[Redirected-Host] 


- 


- 


- 


- 


[Redirected-Host-Usage] 


- 


- 


- 


- 


[Redirected-IVIax-Cache-Time] 


- 


- 


- 


- 


{Result-Code} 


- 


Yes 


- 


Yes 


*[Route-Record] 


No 


- 


No 


- 


<Session-ld> 


Yes 


Yes 


Yes 


Yes 


[User-Name] 


Yes 


Yes 


Yes 


Yes 


[Vendor-Specific-Application-Id] 


Yes 


Yes 


Yes 


Yes 



NOTE: Result-Code AVP is defined in Diameter Base Protocol [3]. However new values are used in IMS 
charging applications. These additional values are defined below. 
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7.1.1 Result-Code AVP 

This subclause defines new Result-Code AVP (Diameter Base Protocol [3]) values that must be supported by all 
Diameter implementations that conform to the present document. 

The Accounting-Answer message includes the Result-Code AVP, which may indicate that an error was present in the 
Accounting-Request message. A rejected Accounting-Request message should cause the user's session to be terminated. 

Errors that fall within the transient failures category are used to inform a peer that the request could not be satisfied at 
the time it was received, but MAY be able to satisfy the request in the future. 

DIAMETER_END_USER_SERVICE_DENIED 40XX 

The ECF denies the service request due to service restrictions or limitations related to the end-user, for example the 
end-user's account could not cover the requested service. 

DIAMETER_CREDIT_CONTROL_NOT_APPLICABLE 40XX 

The credit control server determines that the service can be granted to the end user but no further credit control 
needed for the service (e.g. service is free of charge). 

Errors that fall within permanent failure category are used to inform the peer that the request failed, and should not be 
attempted again. 

DIAMETER_END_USER_NOT_FOUND 50XX 

The specified end user could not be found in the ECF. 

7.1.2 User-Name AVP 

The User-Name AVP contains the Private User Identity [18], if available in the node. 

7.1 .3 Ven(dor-Specific-Application-ld AVP 
7.2 Additional AVPs 

For the purpose of IMS charging additional AVPs are used in ACR and ACA for both online and offline charging. The 
use of these AVPs are described in subclause 5.1.3 for offline charging and in subclause 6.1.3 for online charging. The 
information is summarized in table 7.2 along with the AVP flag rules. 

Detailed descriptions of AVPs that are used specifically for IMS charging are provided in the subclauses below the 
table. However, for AVPs that are just borrowed from other applications only the reference (e.g. [13]), is provided in 
table 7.2 and the detailed description is not repeated. 



£75/ 



3GPP TS 32.225 version 5.4.0 Release 5 



59 



ETSI TS 132 225 V5.4.0 (2003-12) 



Table 7.2: Use Of Diameter Credit Control and 3GPP accounting AVPs for IMS 



AVP Name 


AVP 
Code 


Clause 
Defined 


Value 
Type 


AVP Flag rules 


IVIust May Should IVIust IVIay 
not not Encr. 


AVPs from Diameter Credit Control 


[Subscription-Id] 




[13] 














[Requested-Action] 




[13] 














*[Used-Service-Unit] 




7.2.44 


Grouped 












{Unit-Type} 




7.2.41 


Enumerated 












{Unit-Value} 




7.2.42 


Float64 












{Unit-Value-After-Tariff-Switch} 




7.3.43 


Float64 












[Currency-Code] 




[13] 














[Tariff-Switch-Definition] 




7.2.37 


OctetString 












*[Service-Parameter-lnfo] 




[13] 














[Abnormal-Termination-Reason] 




[13] 














*[Accounting-Correlation-ld] 




[13] 














[Credit-Control-Failure-Handling] 




[13] 














[Direct-Debiting-Failure-Handling] 




[13] 














*[Granted-Service-Unit] 




7.2.19 


Grouped 












{Unit-Type} 




7.2.41 


Enumerated 












{Unit-Value} 




7.2.42 


Float64 












[Unit-Value-After-Tariff-Switch] 




7.3.43 


Float64 












[Currency-Code] 




[13] 














[Cost-Information] 




7.2.13 


Grouped 












{Cost} 




[13] 














{Currency-Code} 




[13] 














[Final-Unit-lndication] 




[13] 














[Check-Balance-Result] 




[13] 














3GPP Diameter Accounting AVPs 


[Event-Type] 




7.2.16 


Grouped 












[SIP-Method] 




7.2.34 


UTFSString 












[Event] 




7.2.15 


UTFSString 












[Content-Type] 




7.2.12 


UTFSString 












[Content-Length] 




7.2.11 


UTFSString 












[Content-Disposition] 




7.2.10 


UTFSString 












[Role-of-Node] 




7.2.27 


Enumerated 












[User Session Id] 




7.2.45 


UTFSString 












[Calling-Party-Address] 




7.2.7 


UTFSString 












[Called-Party-Address] 




7.2.6 


UTFSString 












[Time-stamps] 




7.2.39 


Grouped 












[SIP-Request-Timestamp] 




7.2.35 


UTFSString 












[SIP-Response-Timestamp] 




7.2.36 


UTFSString 












[Application-server] 




7.2.3 


UTFSString 












[Application-provided-called-party-address] 




7.2.2 


UTFSString 












[Inter-Operator-Identifier] 




7.2.22 


Grouped 












[Originating-IOI] 




7.2.25 


UTFSString 












[Terminating-IOI] 




7.2.38 


UTFSString 












[IMS-Charging-ldentifier] 




7.2.20 


UTFSString 












*[SDP-Session-Description] 




7.2.31 


UTFSString 












*[SDP-Media-component] 




7.2.28 


Grouped 












[SDP-Media-Name] 




7.2.30 


UTFSString 












*[SDP-Media-Description] 




7.2.29 


UTFSString 












[GPRS-Charging-ld] 




7.2.18 


UTFSString 












[GGSN-Address] 




7.2.17 


IPAddress 












[Served-Party-IP-Address] 




7.2.32 


IPAddress 












[Authorized-QoS] 




7.2.4 


UTFSString 












[Server-Capabilities] 




[19] 














[Trunk-Group-Id] 




7.2.40 


Grouped 












[Incoming-Trunk-Group-Id] 




7.2.21 


UTFSString 












[Outgoing-Trunk-Group-Id] 




7.2.26 


UTFSString 












[Bearer-Service] 




7.2.5 


OctetString 












[Service-Id] 




7.2. 33 


UTFSString 












[UUS-Data] 




7.2.46 


Grouped 












[Amount-of-UUS-data] 




7.2.1 


UTFSString 












[Mime-type] 




7.2.23 


UTFSString 












[Direction] 




7.2.14 


Enumerated 












[Cause] 




7.2.8 


Grouped 












{Cause-Code} 




7.2.9 


Enumerated 












{Node-Functionality} 




7.2.24 


Enumerated 
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7.2.1 Amount-of-UUS-Data AVP 

The Amount-Of-UUS-Data AVP (AVP code TBD) is of type UTFSString and holds the amount (in octets) of 
User-to-User data conveyed in the body of the SIP message with content-disposition header field equal to "render". 

7.2.2 Application-Provided-Called-Party-Address AVP 

The Application-Provided-Called-Party-Address AVP (AVP code TBD) is of type UTFSString and holds the called 
party number (SIP URL, E.164), if it is determined by an application server. 

7.2.3 Application-Server AVP 

The Application-Server AVP (AVP code TBD) is of type UTFSString and holds the SIP URL(s) of the AS(s) addressed 
during the session. 

7.2.4 Autiiorised-QoS AVP 

The Authorised-QoS AVP (AVP code TBD) is of type UTFSString and holds the Authorised QoS as defined in TS 
23.207 [7] / TS 29.207 [S] and appUed via the Go interface. 

7.2.5 Bearer-Service AVP 

The Bearer-Service AVP (AVP code TBD) is of type OctetString and holds the used bearer service for the PSTN leg. 

7.2.6 Called-Party-Address AVP 

The Called-Party-Address AVP (AVP code TBD) is of type UTFSString and holds the address (Public User ID: SIP 
URL, E.164, etc.) of the party to whom a session is established. 

7.2.7 Calling-Party-Address AVP 

The Calling-Party-Address AVP (AVP code TBD) is of type UTFSString and holds the address (Public User ID: SIP 
URL, E.164, etc.) of the party initiating a session. 

7.2.8 Cause AVP 

The Cause AVP (AVP code TBD) is of type Grouped. The Cause AVP includes the Cause-Code AVP that contains the 
cause value and the Node-Functionality AVP that contains the function of the node where the cause code was 
generated. 

Cause has the following ABNF grammar: 

<Cause>::=<AVP Header: TBD> 

{Cause-Code} 

{ Node-Functionality } 

7.2.9 Cause-Code AVP 

The Cause-Code AVP (AVP code TBD) is of type Enumerated and includes the cause code value from IMS node. It is 
used in Accounting-request [stop] and/or Accounting-request[event] messages. 

Within the cause codes, values < are reserved for successful causes while values > 1 are used for failure causes. In 
case of errors where the session has been terminated as a result of a specific known SIP error code, then the SIP error 
code is also used as the cause code. 

Successful cause code values. 
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"Normal end of session" 

The cause "Normal end of session" is used in Accounting-request[stop] message to indicate that an ongoing SIP 
session has been normally released either by the user or by the network (SIP BYE message initiated by the user 
or initiated by the network has been received by the IMS node after the reception of the SIP ACK message). 

"Successful transaction" -1 

The cause "Successful transaction" is used in Accounting-request[event] message to indicate a successful SIP 
transaction (e.g. REGISTER, MESSAGE, NOTIFY, SUBSCRIBE). It may also be used by an Application Server to 
indicate successful service event execution. 

"End of SUBSCRIBE dialog" -2 

The cause "End of SUBSCRIBE dialog" is used to indicate the closure of a SIP SUBSCRIBE dialog . For 
instance a successful SIP SUBSCRIBE transaction terminating the dialog has been detected by the IMS node 
(i.e. SUBSCRIBE with expire time set to 0). 

"3xx Redirection" -3xx 

The cause "3xx Redirection" is used when the SIP transaction is terminated due to an IMS node 
receiving/initiating a 3xx response [16]. 

Failure cause code values. 

"Unspecified error" 1 

The cause "Unspecified error" is used when the SIP transaction is terminated due to an unknown error. 

" 4xx Request failure" 4xx 

The cause "4xx Request failure" is used when the SIP transaction is terminated due to an IMS node 
receiving/initiating a 4xx error response [16]. 

"5xx Server failure" 5xx 

The cause "5xx Server failure" is used when the SIP transaction is terminated due to an IMS node 
receiving/initiating a 5xx error response [16]. 

"6xx Global failure" 6xx 

The cause "6xx Global failure" is used when the SIP transaction is terminated due to an IMS node 
receiving/initiating a 6xx error response [16]. 

"Unsuccessful session setup" 2 

The cause "Unsuccessful session setup" is used in the Accounting-request[stop] when the SIP session has not 
been successfully established (i.e. Timer H expires and SIP ACK is not received or SIP BYE is received after 
reception of the 200OK final response and SIP ACK is not received) [14] [16]. 

"Internal error" 3 

The cause "Internal error" is used when the SIP transaction is terminated due to an IMS node internal error (e.g. 
error in processing a request/response). 

7.2.10 Content-Disposition AVP 

The Content-Disposition AVP (AVP code TBD) is of type UTFSString and indicates how the message body or a 
message body part is to be interpreted (e.g. session, render), as described in [17]. 



7.2.1 1 Content-Lengtin AVP 



The Content-Length AVP (AVP code TBD) is of type UTFSString and holds the size of the of the message-body, as 
described in [17]. 
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7.2.12 Content-Type AVP 



The Content-Type AVP (AVP code TBD) is of type UTFSString and holds the media type (e.g. application/sdp, 
text/html) of the message -body, as described in [17]. 

7.2.13 Cost-Information AVP 

The Cost-Information AVP (AVP Code TBD) is of type Grouped and is used to return the cost information of a service 
in the Accounting- Answer command. The included Cost AVP contains the cost of the service event and the 
Currency-Code specifies in which currency the cost was given. 

When the Requested-Action AVP with value PRICE_ENQUIRY is included in the Accounting-Request command the 
Cost-Information AVP sent in the succeeding Accounting-Answer command contains the cost estimation of the 
requested service, without any reservation being made. 

The Cost-Information AVP included in the Accounting-Answer command with the Accounting-Record-Type set to 
INTERIM_RECORD contains the accumulated cost for the session without taking any credit- reservation into account. 

The Cost-Information AVP included in the Accounting-Answer command with the Accounting-Record-Type set to 
EVENT_RECORD or STOP_RECORD contains the total cost for the requested service. It has the following ABNF 
grammar. 

When the Requested-Action AVP is set to RESERVE_UNITS in the Accounting-Request (ACR) and the Unit-Type in 
the Requested-Service-Unit AVP is set to SERVICE_CREDIT_MONEY, the Cost-Information AVP sent in the 
succeeding Accounting Answer (ACA) contains the requested cost information. 

It has the following ABNF grammar: 

<Cost-Information>; ;=<AVP Header: TBD> 

{ Cost } 

{ Currency-Code } 

7.2.14 Direction AVP 

The Direction AVP (AVP code TBD) is of type Enumerated and indicates whether the UUS data travels in up-link or 
down-link direction. The following values are defined: 

UPLINK 

DOWNLINK 1 

7.2.15 Event AVP 

The Event AVP (AVP code TBD) is of type UTFSString and holds the content of the "Event" header used in 
SUBSCRIBE and NOTIFY messages. 

7.2.16 Event-Type AVP 

Reflects the type of chargeable telecommunication service/event for which the accounting-request message is 
generated, such as: "session", "register", "subscribe". 

The IMS Event-Type AVP (AVP code TBD) is of type Grouped and contains information about the type of chargeable 
telecommunication service/event for which the accounting-request message is generated. 

It has the following ABNF grammar: 

<IMS-Event-Type>::=<AVP Header: TBD > 

[ SIP-Method] 

[ Event ] 
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[ Content-Type ] 
[ Content-Length ] 
[ Content-Disposition ] 

7.2.17 GGSN-Address AVP 

The GGSN-Address AVP (AVP code TBD) is of type IP Address and holds the IP-address of the GGSN that generated 
the GPRS Charging ID, as described in [2]. 

7.2.18 GPRS-Charging-ID AVP 

The GPRS-Charging-ID AVP (AVP code TBD) is of type UTFSString and holds a sequence number generated by the 
GGSN at PDP context activation, as described in [2]. 

7.2.19 Granted-Service-Unit AVP 

If the ACA containing the Granted-Service-Unit AVP contains a Tariff-Switch-Definition AVP, the Unit-Value-After- 
Tariff-Switch AVP may be included. In this case the Unit-Value AVP contains the granted units before the tariff switch 
time and the Unit-Value-After-Tariff-Switch AVP gives the units granted after the tariff switch. 

If the ACA containing the Granted-Service-Unit AVP contains a Tariff-Switch-Definition AVP but no Unit-Value- 
After-Tariff-Switch AVP is included, the granted Unit-Value is used before and after the tariff switch. 

An ACA containing a Granted-Service-Unit AVP with Unit-Value-After-Tariff-Switch AVP MUST contain a Tariff- 
Switch-Definition AVP. If the Tariff-Switch-Definition AVP is missing, the Unit-Value-After-Tariff-Switch AVP is 
ignored and it is proceeded as without a tariff change. 

It has the following ABNF grammar: 

<Granted-Service-Unit>::=< AVP Header: TBD > 

{ Unit-Type } 

{ Unit- Value } 

[ Unit- Value- After-Tariff Switch ] 

[ Currency-Code ] 

7.2.20 IMS-Charging-ldentifier (ICID) AVP 

The IMS-Charging-Identifier AVP (AVP code TBD) is of type UTFSString and holds the IMS Charging Identifier 
(ICID) as generated by a IMS node for a SIP session and described in subclause 5.2.4.10. 

7.2.21 Incoming-Trunk-Group-ID AVP 

The Incoming-Trunk-Group-ID AVP (AVP code TBD) is of type UTFSString and identifies the incoming PSTN leg. 

7.2.22 Inter-Operator-Identifier (101) AVP 

The Inter-Operator-Identifier AVP (AVP code TBD) is of type Grouped and holds the identification of the network 
neighbours (originating and terminating) as exchanged via SIP signalling and described in [15]. 

It has the following ABNF grammar: 

<Inter-Operator-Identifier>::=< AVP Header: TBD > 

[ Originating-IOI ] 

[ Terminating-IOI ] 
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7.2.23 Mime-Type AVP 

The Mime-Type AVP (AVP code TBD) is of type UTFSString and holds the Mime type of the User-To-User data. 

7.2.24 Node-Functionality AVP 

The Node-Functionality AVP (AVP code TBD) is of type Enumerated and includes the functionality identifier of the 
node where the cause code was generated. 



Thef 


unctionalit; 


y identifier can be one of the folh 


3 wing; 




S-CSCF 









P-CSCF 


1 






I-CSCF 


2 






MRFC 


3 






MGCF 


4 






BGCF 


5 






AS 


6 






UE 


7 





7.2.25 Originating-IOI AVP 

The Originating-IOI AVP (AVP code TBD) is of type UTFSString (alphanumeric string) and holds the Inter Operator 
Identifier for the originating network as generated by the S-CSCF in the home network of the originating end user [15]. 

7.2.26 Outgoing-Trunl<-Group-ID AVP 

The Outgoing-Trunk-Group-ID AVP (AVP code TBD) is of type UTFSString and identifies the outgoing PSTN leg. 

7.2.27 Role-of-Node AVP 

The Role-Of-Node AVP (AVP code TBD) is of type Enumerated and specifies the role of the AS/CSCF. 

The identifier can be one of the following: 

ORIGINATING_ROLE 

The AS/CSCF is applying a originating role, serving the calling subscriber. 

TERMINATING_ROLE 1 

The AS/CSCF is applying a terminating role, serving the called subscriber. 

PROXY ROLE 2 

The AS is applying a proxy role. 

B2BUA_ROLE 3 

The AS is applying a B2BUA role. 



7.2.28 SDP-Media-Component AVP 



The SDP- Media-Component AVP (AVP code TBD) is of type Grouped and contains information about media used for 
a IMS session. 

It has the following ABNF grammar: 

<SDP-Media-Component>::=<AVP Header: TBD > 
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[ SDP-Media-Name ] 

*[ SDP-Media-Description ] 

[ GPRS-Charging-Id ] 

7.2.29 SDP-Media-Description AVP 

The SDP-Media-Description AVP (AVP code TBD) is of type UTFSString and holds the content of an "attribute-hne" 
(i=, c=, b=, k=, a=, etc.) related to a media component, as described in [17]. The attributes are specifying the media 
described in the SDP-Media-Name AVP. 

7.2.30 SDP-Media-Name AVP 

The SDP-Media-Name AVP (AVP code TBD) is of type UTFSString and holds the content of a "m=" line in the SDP 
data. 

7.2.31 SDP-Session-Description AVP 

The SDP-Media-Description AVP (AVP code TBD) is of type UTFSString and holds the content of an "attribute-line" 
(i=, c=, b=, k=, a=, etc.) related to a session, as described in [17]. 

7.2.32 Served-Party-IP-Address AVP 

The Served-Party-IP-Address AVP (AVP code TBD) is of type IP Address and holds the IP address of either the calling 
or called party, depending on whether the P-CSCF is in touch with the calling or the called party. This AVP is only 
provided by die P-CSCF. 

7.2.33 Service-ID AVP 

The Service-ID AVP (AVP code TBD) is of type UTFSString and identifies the service the MRFC is hosting. For 
conferences the conference ID is used as the value of this parameter. 

7.2.34 SIP-Method AVP 

The SIP-Method AVP (AVP code TBD) is of type UTFSString and holds the name of the SIP Method (INVITE, 
UPDATE etc.) causing an accounting request to be sent to the CCF. 



7.2.35 SIP-Request-Timestamp AVP 

The SIP-Request-Timestamp AVP (AVP code TBD) is of type UTFSString and holds the time in UTC format of the 
initial SIP request (e.g. Invite). 

7.2.36 SIP-Response-TimestampAVP 

The SIP-Response-Timestamp AVP (AVP code TBD) is of type UTFSString and holds the time in UTC format of the 
response to the initial SIP request (e.g. 200 OK). 

7.3.37 Tariff-Switcin-Definition AVP 

The Tariff-Switch-Definition AVP (AVP Code TBD) is of type OctetString and contains the tariff switch timer. 

This AVP can be included in the Accounting Answer which is sent as a result of the previous Accounting Request with 
Requested-Action AVP set to RESERVE_UNITS. The tariff switch timer is evaluated relative to the timestamp of the 
preceding Accounting Request command. When the tariff switch timer expires, the AS/MRFC uses the 
Unit-Value-After-Tariff-Switch, if provided in the ACA, as granted units. 
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If a tariff switch has occurred, the Tariff-Switch-Definition AVP should be included in the next ACR together with the 
units used before the tariff switch (Unit-Value AVP) and the units used after the tariff switch 
(Unit-Value-After-Tariff-SwitchAWP). 

7.2.38 Terminating-IOI AVP 

The Terminating-IOI AVP (AVP code TBD) is of type UTFSString (alphanumeric string) and holds the Inter Operator 
Identifier for the originating network as generated by the S-CSCF in the home network of the terminating end user [15]. 

7.2.39 Time-Stamps AVP 

The Time-Stamp AVP (AVP code TBD) is of type Grouped and holds the time of the initial SIP request and the time of 
the response to the initial SIP Request. 

It has the following ABNF grammar: 

<Time-Stamps>::=< AVP Header: TBD > 

[SIP-Request-Timestamp] 

[SIP-Response-Timestamp] 

7.2.40 Trunk-Group-ID AVP 

The Trunk-Group-ID AVP (AVP code TBD) is of type Grouped and identifies the incoming and outgoing PSTN legs. 
It has the following ABNF grammar: 

<Trunk-Group-ID>::=<AVP Header: TBD> 

[ Incoming-Trunk-Group-ID ] 

[ Outgoing-Trunk-Group-ID ] 

7.2.41 Unit-Type AVP 

The Unit-Type AVP is of type Enumerated (AVP Code TBD) and contains the type of the unit. The unit type can be one 
of the following: 

SERVICE_CREDIT_TIME 

The unit is of type "time" and is given in seconds. 

SERVICE_CREDIT_VOLUME 1 

The unit is of type "volume" and is given in kB. 

SERVICE_CREDIT_EVENT 2 

The unit is of type "event" and is given as a number of events. 

SERVICE_CREDIT_MONEY 3 

The unit is of type "money" and is given as a monetary value, whose currency SHOULD be specified by the 
Currency-Code AVP. 

SERVICE_CREDIT_SERVICE 4 

The unit of type "service" and is given as a selected service. 
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7.2.42 Unit- Value AVP 

The Unit-Value AVP is of type Float64 (AVP Code TBD) and contains the granted or used Unit- Value. The value can 
be time in seconds, volume in kB, number of events or monetary amount depending on the given Unit-Type. 

If the Unit-Type AVP is set to "time" in the Accounting-Answer command, the Unit Value AVP specifies the granted 
time in seconds (measured from the moment when the services becomes active or from the previous Answer command) 
until a new Accounting-Request MUST be sent. 

If the Unit Type AVP is set to "time" in Xhe Accounting-Request command, the Unit-Value AVP specifies the used time 
since previous report or time requested by the service element (e.g. AS/MRFC). 

If the Unit-Type AVP is set to "volume" in the Accounting-Answer command, the Unit-Value AVP specifies the granted 
volume in kB (measured from the moment when the services becomes active or from the previous Answer command) 
until a new Accounting-Request MUST be sent. If the Unit-type AVP is set to "volume" in the Accounting-Request 
command, the Unit-Value AVP specifies the used volume since previous report or volume requested by service element 
(e.g. AS/MRFC). 

If the Unit-Type AVP is set to "event" in the Accounting-Answer command, the Unit-Value AVP specifies the granted 
number of events (measured from the moment when the service becomes active or from the previous Answer 
command) until a new Accounting-Request MUST be sent. If the Unit-type AVP is set to "event" in the Accounting- 
Request command, the Unit-Value AVP specifies the used number of events since previous report or number of events 
requested by the service element (e.g. AS/MRFC). 

If the Unit-Type AVP is set to "money" in the Accounting-Answer command, the Unit-Value AVP specifies the granted 
monetary amount, which the end user can use until a new Accounting-Request MUST be sent. If the Unit-Type AVP is 
set to "money" in the Accounting-Request command, the Unit-Value AVP specifies the used monetary amount since 
previous report or the monetary amount requested by the service element (e.g. AS/MRFC). 

If the Accounting-Answer command contains a Tariff-Switch-Definition AVP and a Unit-Value-After-Tariff-Switch 
AVP, the Unit-Value AVP in the Accounting-Answer contains the amount of units granted before the tariff change. In 
this case, the following holds: 

• If the Unit-Type AVP is set to "time" in the Accounting-Answer command, the Unit Value AVP specifies the 
granted time before the tariff switch in seconds (measured from the moment when the services becomes active or 
from the previous Answer command) until the tariff switch occurs or a new Accounting-Request MUST be sent. 

• If the Unit-Type AVP is set to "volume" in the Accounting-Answer command, the Unit-Value AVP specifies the 
granted volume before the tariff switch in kB (measured from the moment when the services becomes active or 
from the previous Answer command) until the tariff switch occurs or a new Accounting-Request MUST be sent. 



• 



• 



If the Unit-Type AVP is set to "event" in the Accounting-Answer command, the Unit-Value AVP specifies the 
granted number of events before the tariff switch (measured from the moment when the service becomes active 
or from the previous Answer command) until the tariff switch occurs or a new Accounting-Request MUST be 
sent. 

If the Unit-Type AVP is set to "money" in the Accounting-Answer command, the Unit-Value AVP specifies the 
granted monetary amount before the tariff switch, which the end user can use until the tariff switch occurs or a 
new Accounting-Request MUST be sent. 

If the Accounting-Answer command contains a Tariff-Switch-Deftnition AVP but no Unit-Value-After-Tariff-Switch 
AVP, the Unit-Value AVP in the Accounting- Answer contains the total amount of units granted irrespective of the tariff 
change. 

If the Accounting-Answer command contains a Tariff-Switch-Deftnition AVP and a tariff switch occurred, the next 
Accounting-Request contains the Unit-Value AVP and the Unit-Value-After-Tariff-Switch AVP. The Unit-Value AVP 
contains the service units used before the tariff switch. 

7.3.43 Unit-Value-After-Tariff-Switch AVP 

The Unit-Value-After-Tariff-Switch AVP is of type Float64 (AVP Code TBD) and contains the granted or used 
Unit-Value after a tariff switch. The value can be time in seconds, volume in kB, number of events or monetary amount 
depending on the given Unit-Type. 



ETSI 



3GPP TS 32.225 version 5.4.0 Release 5 68 ETSI TS 1 32 225 V5.4.0 (2003-1 2) 

The Unit-Value-After-Tariff-Switch AVP can only occur in combination with a Tariff-Switch-Definition AVP. 

If the Unit-Type AVP is set to "time" in the Accounting-Answer command, the Unit-Value-After-Tariff-Switch AVP 
specifies the granted time in seconds (measured from the moment when the tariff change occurs) until a new 
Accounting-Request MUST be sent. 

If the Unit Type AVP is set to "time" in the Accounting-Request command, the Unit-Value-After-Tariff-Switch AVP 
specifies the used time after tariff switch. 

If the Unit-Type AVP is set to "volume" in the Accounting-Answer command, the Unit-Value-After-Tariff-Switch AVP 
specifies the granted volume in kB (measured from the moment when the tariff change occurs) until a new 
Accounting-Request MUST be sent. If the Unit-type AVP is set to "volume" in the Accounting-Request command, the 
Unit-Value-After-Tariff-Switch AVP specifies the used volume after tariff switch. 

If the Unit-Type AVP is set to "event" in the Accounting-Answer command, the Unit-Value-After-Tariff-Switch AVP 
specifies the granted number of events (measured from the moment when the tariff change occurs) until a new 
Accounting-Request MUST be sent. If the Unit-type AVP is set to "event" in the Accounting-Request command, the 
Unit-Value-After-Tariff-Switch AVP specifies the used number of events after tariff switch. 

If the Unit-Type AVP is set to "money" in the Accounting-Answer coramand, the Unit-Value-After-Tariff-Switch AVP 
specifies the granted monetary amount, which the end user can use (measured from the moment when the tariff change 
occurs) until a new Accounting-Request MUST be sent. If the Unit-Type AVP is set to "money" in the 
Accounting-Request command, the Unit-Value-After-Tariff-Switch AVP specifies the used monetary amount after tariff 
switch. 

7.2.44 Used-Service-Unit AVP 

The Used-Service-Unit AVP is of type Grouped AVP (AVP Code TBD) and contains the amount of used units since the 
previous Accounting-Answer command. The included Unit-Type AVP defines the type of the unit and the Unit-Value 
AVP contains the used amount. If the unit type is "money", a Currency-Code AVP SHOULD be included. 

If the previous ACA contained a Tariff-Switch-Definition AVP, the Unit-Value-After-Tariff-Switch AVP must be 
included in the Used-Service-Unit AVP in the ACR, if the tariff switch was encountered. In this case the Unit-Value 
AVP contains the units used before the tariff switch and the Unit-Value-After-Tariff-Switch AVP gives the units used 
after the tariff switch. 

It has the following ABNF grammar: 

<Used-Service-Unit>::=< AVP Header: TBD > 

{ Unit-Type } 

{ Unit- Value } 

{ Unit-Value-After-Tariff-Switch } 

[ Currency-Code ] 

7.2.45 User-Session-ID AVP 

The User-Session-Id AVP (AVP code TBD) is of type UTFSString and holds the session identifier. For a SIP session 
the Session-ID contains the SIP Call ID, as defined in [16]. 

7.2.46 UUS-Data AVP 

The UUS-Data AVP (AVP Code TBD) is of type Grouped AVP and holds information about the sent User-To-User 
data. 

It has the following ABNF grammar: 

<Used-Service-Unit>::=< AVP Header: TBD > 

[Amount-of-UUS-Data] 
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[Mime-Type] 
[Direction] 



£75/ 



3GPP TS 32.225 version 5.4.0 Release 5 70 ETSI TS 1 32 225 V5.4.0 (2003-1 2) 



Annex A (Normative): 

Diameter Credit Control Application 



The document included in this Annex is the latest available Internet-Draft at the time of writing. When the IETF issues 
the RFC to this Internet-Draft then a change request will be provided to replace the text in Annex A with a reference in 
clause 2. 

Harri Hakala, 
Leena Mattila 
INTERNET-DRAFT Ericsson, 

Draft : <draf t-hakala-diameter-credit-control-05 . txt> Juha-Pekka 
Expires: May 2003 Koskinen, 

Marco Stura 
Nokia 

November 2002 



Diameter Credit Control Application 
Status of this memo 



This document is an Internet-Draft and is subject to all provisions 
of Section 10 of RFC2026. 

Internet-Drafts are working documents of the Internet Engineering 
Task Force (IETF), its areas, and its working groups. Note that 
other groups may also distribute working documents as Internet- 
Drafts . 

Internet-Drafts are draft documents valid for a maximum of six 
months and may be updated, replaced, or obsoleted by other documents 
at any time. It is inappropriate to use Internet-Drafts as reference 
material or cite them other than as "work in progress". 

The list of current Internet-Drafts can be accessed at 
http : //www .ietf.org/ietf/lid-abstracts.txt 

The list of Internet-Draft Shadow Directories can be accessed at 
http : //www . ietf . org/ shadow . html 

This document is an individual submission to the IETF. Comments 
should be directed to the authors. 



Abstract 

This document specifies a Diameter application that is used for real- 
time cost and credit control between a service element and a credit 
control server in service environment. 

Diameter accounting messages with additional AVPs are used to 
transfer service and credit control information between the service 
element and the credit control server. 
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1 Introduction 

This Diameter application, combined with the Diameter base protocol 
[DIAMBASE], describes the accounting protocol that can be used for 
real time cost and credit control in the service environment. 

The next generation wireless networks specify (e.g. 3G Charging and 
Billing requirements [3GPPCHARG]) more critical requirements for the 
accounting applications. The accounting application must be able to 
rate accounting information in real-time. For example, for the 
service environment it is vital to be able to rate service event 
information instantly. 

There also exists a demand for the end user credit control. The 
accounting application must be able to check the end user's account 
for coverage for the requested service event charge prior to 
execution of that service event. All the chargeable events related to 
a specific account must be prevented from the end user when the 
credit of that account is exhausted or expired. 

Also a mechanism should be provided to indicate to the end user of 
the charges to be levied for a chargeable event. 

There are as well services such as gaming or advertising that in some 
situations rather refund than deduct the end user's account. 

To fulfill all these needs a new type of accounting application is 
needed, the credit control application. This application is used for 
real-time delivery of service event information in the service 
environment from the service element to the credit control server to 
minimize the financial risk. 

1.1. Requirements language 

In this document, the key words "MAY", "MUST, "MUST NOT", "optional", 
"recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as 
described in [KEYWORDS] . 

1.2 Terminology 

AAA 
Authentication, Authorization and Accounting 
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Accounting 

The act of collection of information on resource usage for the 
purposes of trend analysis, auditing, billing or cost allocation. 

Accounting Server 

The accounting server receives accounting data from the service 
elements and other devices and translates it into session records. 
It acts as an interface to back-end rating, billing, and operations 
support systems . 

Charging 

In the telecom world charging is synonym to accounting. A function 
whereby information related to a chargeable event is transferred in 
order to make it possible to determine usage for which the charged 
party may be billed. 

Credit Control 

Credit control is a mechanism, which directly interacts in real- 
time with an account and controls or monitors the charges, related 
to the service usage. Credit control is a process of checking if 
credit is available, credit-reservation, reduction of credit from 
the end user account when service is completed and refunding of 
reserved credit not used. 

Credit Control Server 

It is located in the home environment and is accessed by service 
elements in real-time for purpose of price determination and credit 
control before the service event is delivered to the end-user. It 
may also interact with business support systems. 

Diameter Credit Control Client 

A Diameter credit control client is an entity that interacts with a 
credit control server. 

Diameter Credit Control Server 

A Diameter credit control server is an entity that handles credit 
control request. 

Rating 

The act of determining the cost of the service event . 

Service 

A type of task that is performed by a service element for an end 
user . 

Service Element 

A network element that provides a service to end user. A service 
element itself can include the application service providers or 
application service providers can be located in an other domain. 

Service Event 

Any event which creates value for the end-user. 

1.3 Advertising application support 

Diameter nodes conforming to this specification MAY advertise support 

by including the value of TBD (X) in the Acct-Application-Id AVP of 

the Capabilities-Exchange-Request and Capabilities-Exchange-Answer 
command [DIAMBASE] . 

2 Architecture Model 
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A service element provides services to end-users. When accounting is 
used a service element collects service event information and reports 
it while and/or after services are provided to an accounting server 
by using an accounting protocol. Alternatively the accounting server 
may query the service element for service event information. 

The accounting protocol can for example be RADIUS accounting protocol 
or the Diameter base protocol with a Diameter application. 

If real-time credit control is required, the service element (credit 
control client) contacts the credit control server with service event 
information included before the service is provided. The credit 
control server, depending on the service event information, MAY 
perform the rating of the service event, pricing of the service 
event, credit check and credit-reservation from the account. The 
service element monitors the service execution according to the 
instructions returned by the credit control server. After the service 
completion the credit control server deducts the money from the 
account . 

If direct debiting/refunding is requested, the credit control server 
deducts/increases the end user's account, respectively. The service 
element can also enquire the price of the service or the account 
balance status from the credit control server. 

In a multi-service environment it might happen that an end user with 
already ongoing service (e.g. voice call) issues a new service 
request (e.g. data service) towards same account or during an active 
multimedia session an additional media type is added to the session 
causing a new simultaneous request towards same account. Consequently 
this SHOULD be considered when units are granted to the services. 

There MAY be multiple credit control servers in the system for 
reasons of redundancy and load balancing. The system MAY also contain 
separate rating server (s) and accounts MAY locate in a centralized 
database. System internal interfaces can exist to relay messages 
between servers and an account manager. However the detailed 
architecture of credit control system and its interfaces are 
implementation specific and are out of scope of this specification. 

The credit control protocol is the Diameter base protocol with the 
Diameter credit control application. 



accounting 
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The credit control server and accounting server in this architecture 
model are logical entities. The real configuration MAY combine them 
into a single host. 

There MAY exist protocol transparent Diameter relays and redirect 
agents between credit control client and credit control server. These 
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agents transparently support the Diameter credit control application. 

If Diameter credit control proxies exist between the credit control 
client and the credit control server, they MUST advertise the 
Diameter credit control application support. 

3 Service Control 

When an end user requests a service the request is forwarded to a 
service element in the home domain, that is the same administrative 
domain, in which the end user's credit control server is located. In 
some cases it might be possible that the service element in the 
visited domain can offer service event to the end user, but in that 
case a commercial agreement must exist between the service element in 
the visited domain and in the home domain. 

The service element SHOULD authenticate and authorize the end user 
before any request is sent to the credit control server. The way how 
the authentication and/or authorization are performed in the service 
element and the authentication and/or authorization messages that are 
used are not defined in this application. The methods defined in 
other Diameter applications or other legacy authentication and 
authorization methods can be used. 

Each credit control session MUST have globally unique Session-Id as 
defined in [DIAMBASE] and it MUST NOT be changed during the life time 
of a credit control session. 

The Diameter credit control client in the service element MAY get 
information from the authorization server regarding the way 
accounting data shall be forwarded (accounting protocol, credit 
control protocol or both) based on its knowledge of the end user. 
This means that the accounting information is forwarded to the 
accounting server as defined in [DIAMBASE], the credit control 
server SHOULD be contacted before the service event is offered to the 
end user or both the accounting protocol and the credit control 
protocol MAY be used in parallel. 

The authorization server MAY include the Accounting-Realtime-Required 
AVP to determine what to do if the sending of accounting records to 
the accounting server has been temporarily prevented as defined in 
[DIAMBASE] . The Accounting-Realtime-Required AVP is not used by this 
application. Instead of or in addition to the Accounting-Realtime- 
Required AVP the authorization server MAY include the Credit-Control- 
Failure-Handling AVP and Direct-Debiting-Failure-Handling AVP to 
determine what to do if the sending of credit control messages to the 
credit control server has been temporarily prevented. The usage of 
Credit-Control-Failure-Handling AVP and the Direct-Debiting-Failure- 
Handling AVP gives flexibility to have different failure handling for 
credit control session and one time event direct debiting. The credit 
control server MAY override the failure handling for credit control 
session by including the Credit-Control-Failure-Handling AVP in the 
Accounting-Answer . 

The usage of separate AVPs malces it possible to have different 
failure handling towards accounting servers and credit control 
servers, in case both should be used parallel. It is recommended that 
the client complements the credit control failure procedures with 
bacJtup accounting flow towards an accounting server. With different 
combinations of above AVPs different safety levels can be built. 
For example by choosing the Credit-Control-Failure-Handling AVP equal 
to CONTINUE and Accounting-Realtime-Required AVP equal to 
DELIVER_AND_GRANT the service can be granted to the end user even if 
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the connection to the credit control server is down but the 
accounting server is able to collect the accounting information, 
provided that there is information exchange taking place between the 
accounting server and credit control server. 

If authentication and authorization is done based on Diameter 
application the authorization server MAY include the Acct-Interim- 
Interval AVP to control the operation of the device in the service 
element operating as a client as defined in [DIAMBASE] . If the Acct- 
Interim-Interval AVP is included then the interim interval MAY be 
present in the request message sent to the credit control server. 

The Diameter credit control server MAY override the interim interval. 
It is up to the credit control server to determine, even 
independently from the requested value, the allowed interim interval 
to be used for consumption of the granted service units. The credit 
control server MAY return the interim interval in the Answer message 
to the credit control client. It can be included in the Answer 
message even in case it is not present in the Request message. 
Alternatively the accounting interim interval can be omitted from the 
Answer message. However, since interim records are also produced at 
the expiry of granted service units and/or for mid-session service 
events the omission of Acct-Interim-Interval does not mean that 
interim records are not produced. 

During authorization, the authorization server MAY return the 
Accounting-Multi-Session-Id, which the Diameter credit control client 
MAY include in all subsequent accounting messages. The Accounting- 
Multi-Session-Id AVP MAY include the value of the original Session- 
Id. It's contents are implementation specific, but MUST be globally 
unique across other Accounting-Multi-Session-Id, and MUST NOT be 
changed during the life time of a credit control session. 
There are certain applications that require multiple accounting sub- 
sessions. Such applications would send messages with a constant 
Session-Id AVP, but a different Accounting Sub-Session-Id AVP. 
If several credit sub-sessions will be used, all sub-sessions MUST be 
closed separately before the closing the main session. The absence of 
this AVP implies no sub-sessions are in use. 

If the credit control client wants to perform credit-reservation 
before granting service to the end user it MUST use several 
interrogations towards the credit control server. In this case the 
credit control server MUST maintain the accounting session state. 

A one time event MAY be used when there is no need to maintain any 
state in the Diameter credit control server, for example enquiring 
the price of the service. 

3.1 Session Based Credit Control 

For a session based credit control several interrogations are needed: 
the first, intermediate (optional) and the final interrogation. 

3.1.1 First Interrogation 

The first interrogation MUST be sent before the Diameter credit 
control client in a service element allows any service event to the 
end user. The Accounting-Record-Type is set to the value START_RECORD 
in the first request message. The Subscription-Id-Data AVP SHOULD be 
included to identify the end-user in the credit control server. 

If the Diameter credit control client knows the cost of the service 
event the monetary amount to be charged is included in the Requested- 
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Service-Unit AVP . If the Diameter credit control client does not know 
the cost of the service event, the Requested-Service-Unit AVP MAY 
contain the number of requested service events and the Service- 
Parameter-Info AVP SHOULD contain the service event information to be 
rated by the credit control server. The Service-Parameter-Info AVP 
always refers to the requested service units. 

The Event-Timestamp AVP contains the time when the service event is 
requested in the service element. 

The credit control server SHOULD rate the service event and make a 
credit-reservation from the end user's account that covers the cost 
of the service event. If the type of the Requested-Service-Unit AVP 
is money, no rating is needed but the corresponding monetary amount 
is reserved from end user's account. 

The credit control server returns the Granted-Service-Unit AVP in the 
Answer message to the Diameter credit control client. The Granted- 
Service-Unit AVP contains the amount of service units that the 
Diameter credit control client can provide to the end user until a 
new Accounting-Request MUST be sent to the credit control server. If 
several unit types are sent in the Answer message the credit control 
client MUST handle each unit type separately. However there MUST be 
maximum one instance of the same unit type in one Answer message. 
When the granted service units for one unit type have been spent a 
new Accounting-Request MUST be sent to the credit control server even 
though there would be service units left for other units types. The 
type of the Granted-Service-Unit AVP can be time, volume, service 
specific or money depending on the type of service event. It is not 
allowed to change the unit type(s) within the session. 

If the credit control server determines that no further control is 
needed for the service it MAY include the result code indicating that 
the credit control is not applicable (e.g. service is free of charge) 
and terminate the credit control session. 

The Accounting-Answer message MAY also include the Final-Unit- 
Indication AVP to indicate that the Answer message contains the final 
units for the service session. After the end user has used these 
units, the Diameter credit control client is responsible for 
terminating the service session and the credit control session by 
sending the final interrogation to the credit control server. 

3.1.2 Intermediate Interrogation 

When all the granted service units for one unit type are spent by the 
end user or the interim interval is expired the Diameter credit 
control client MUST send a new Accounting-Request to the credit 
control server. In case the Acct-Interim-Interval is used it is 
always up to the Diameter credit control client to send a new request 
well in advance before the expiration of the previous request in 
order to avoiding interruption in the service element. Even if the 
granted service units reserved by the credit control server have not 
been spent upon expiration of the accounting interim interval, the 
Diameter credit control client MUST send a new Accounting-Request to 
the credit control server. 

There can be also mid-session service events, which might affect the 
rating of the current service events. In this case a spontaneous 
updating (a new Accounting-Request) SHOULD be sent including 
information related to the service event even if all the granted 
service units have not been spent or the accounting interim interval 
has not expired. 
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When the used units are reported to the credit control server the 
credit control client will not have any units in its possession 
before new granted units are received from the credit control server. 
When the new granted units are received from the credit control 
server these units apply from the point where the measurement of the 
reported used units stopped. 

The Accounting-Record-Type AVP is set to the value INTERIM_RECORD in 
the intermediate request message. The Subscription-Id-Data AVP SHOULD 
also be included in the intermediate message to identify the end user 
in the credit control server. 

The Requested-Service-Unit AVP contains the new amount of requested 
service units. The Used-Service-Unit AVP contains the amount of used 
service units measured from the point when the service became active 
or, in case of interim interrogations are used during the session, 
from the point when the previous measurement ended. The same unit 
types that are used in the previous message MUST be used. If several 
unit types were included in the previous Answer message the used 
service units for each unit type MUST be reported. 

The Event-Timestamp AVP contains the time of the event that triggered 
the sending of the new Accounting-Request. 

The credit control server MUST deduct the used monetary amount from 
the end user's account. It MAY rate the new request and make a new 
credit-reservation from the end user's account that covers the cost 
of the requested service event. 

The Accounting-Answer message with the Accounting-Record-Type AVP set 
to the value INTERIM_RECORD MAY include the Cost-Information AVP 
containing the accumulated cost estimation for the session without 
taking any credit-reservation into account. 

There MAY be several intermediate interrogations within a session. 

3.1.3 Final Interrogation 

When the end user terminates the service session or when all the 
granted units are used after a Final-Unit-Indication AVP has been 
received from the credit control server, the Diameter credit control 
client MUST send a final Accounting-Request message to the credit 
control server. The Accounting-Record-Type AVP is set to the value 
STOP_RECORD. 

The Event-Timestamp AVP MAY contain the time of the session was 
terminated. 

The Used-Service-Unit AVP contains the amount of used service units 
measured from the point when the service became active or, in case of 
interim interrogations are used during the session, from the point 
when the previous measurement ended. If several unit types were 
included in the previous answer message the used service units for 
each unit type MUST be reported. 

After final interrogation the credit control server MUST refund the 
reserved credit amount not used to the end user's account and deduct 
the used monetary amount from the end user's account. 

The Accounting-Answer message with the Accounting-Record-Type set to 
the value STOP_RECORD SHOULD include the Cost-Information AVP 
containing the estimated total cost for the session in question. 
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3.1.4 Failure Procedures 

Since the credit control application is based on real-time bi- 
directional communication between the credit control client and the 
credit control server alternative destinations and buffering of 
messages are not sufficient in the event of communication failures. 
Since the credit control server has to maintain a session state the 
credit control message stream MUST not be moved to a backup credit 
control server during an ongoing credit control session. However, 
Diameter agents MAY perform failover to an alternative agent when 
they detect a transport failure. As a consequence the credit control 
server MAY receive duplicate messages. These duplicates or out of 
sequence messages can be detected in the credit control server based 
on the credit control server session state machine (section 3.3), 
Session-Id AVP and Accounting-Record-Number AVP . 

If a communication failure occurs during an ongoing credit control 
session the credit control client will terminate or continue the 
service depending on the value set in the Credit-Control-Failure- 
Handling AVP. The Credit-Control-Failure-Handling AVP MAY be sent 
from the authorization server and in the Accounting-Answer from the 
credit control server. For new credit control sessions failover to 
alternative credit control server SHOULD be performed, if possible. 

The timer Tx (as defined in section 8) is used in the credit control 
client to supervise the communication with the credit control server. 

If the credit control server detects a failure during an ongoing 
credit control session it will terminate the credit control session 
and return the reserved units back to the end user's account. 

The supervision session timer Ts as defined in [DIAMBASE] is used in 
the credit control server. 

3.2 One Time Event 

The one time event is used when there is no need to maintain 
accounting session state in the credit control server. 

The one time event can be used when the service element wants to know 
the cost of the service event without any credit-reservation or to 
check the account balance without any credit-reservation. It can be 
used also for refunding service units on the user's account or direct 
debiting without any credit-reservation. 

3.2.1 Service Price Enquiry 

Sometimes the service element needs to know the price of the service 
event. There might exist services offered by application service 
providers, whose prices are not known in the service element. End 
user might also want to get an estimation of the price of a service 
event before requesting it. 

A Diameter credit control client requesting the cost information MUST 
set the Accounting-Record-Type AVP equal to EVENT_RECORD, include the 
Requested-Action AVP set to PRICE_ENQUIRY and set the requested 
service event information into the Service-Parameter-Info AVP in the 
Accounting-Request message. 

The credit control server calculates the cost of the requested 
service event, but it does not perform any account balance check or 
credit-reservation from the account. 
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The estimated price of the requested service event is returned to the 
credit control client in the Cost-Information AVP in the Accounting- 
Answer message. 

3.2.2 Balance Check 

Sometimes Diameter credit control client needs only to verify that 
the end user's account balance covers the cost for a certain service 
without reserving any units from the account at the time of the 
enquiry. This method does not guarantee that there would be credit 
left when the Diameter credit control client requests the debiting of 
the account with a separate request. 

A Diameter credit control client requesting the balance check MUST 
set the Accounting-Record-Type AVP equal to EVENT_RECORD, include 
Requested-Action AVP set to CHECK_BALANCE and include the 
Subscription-Id-Data to identify the End-User in the credit control 
server . 

The credit control server makes the balance check, but it does not do 
any credit-reservation from the account. 

The result of balance check (Credit/No Credit) is returned to the 
credit control client in the Check-Balance-Result AVP in the 
Accounting-Answer message. 

3.2.3 Direct Debiting 

There are certain one time events for which service execution is 
always successful in the service environment. Sometimes the delay 
between the service invocation and the actual service delivery to the 
end user can be so long that the use of the session based credit 
control would lead to unreasonable long credit control sessions. 
In these cases the Diameter credit control client can use the one 
time event scenario for direct debiting. The Diameter credit control 
client SHOULD be sure that the requested service event execution will 
be successful, when this scenario is used. 

The Accounting-Record-Type is set to the value EVENT_RECORD and the 
Requested-Action AVP set to DIRECT_DEBITING in the Accounting-Request 
message. The Subscription-Id-Data AVP SHOULD be included to identify 
the End-User in the credit control server. The Event-Timestamp AVP 
contains the time when the service event is requested in the service 
element . 

The Diameter credit control client MAY include the monetary amount to 
be charged in the Request-Service-Unit AVP, if it knows the cost of 
the service event. If the Diameter credit control client does not 
know the cost of the service event, then the Service-Parameter-Info 
AVP SHOULD contain the service event information to be rated by the 
credit control server. The Service-Parameter-Info AVP always refers 
to the requested service unit. 

The credit control server SHOULD rate the service event and deduct 
the corresponding monetary amount from end user's account. If the 
type of the Requested-Service-Unit AVP is money, no rating is needed 
but the corresponding monetary amount is deducted from the End User's 
account . 

The credit control server returns the Granted-Service-Unit AVP in the 
Answer message to the Diameter credit control client. The Granted- 
Service-Unit AVP contains the amount of service units that the 
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Diameter credit control client can provide to the end user. The type 
of the Granted-Service-Unit can be time, volume, service specific or 
money depending on the type of service event . 

If the credit control server determines that no credit control is 
needed for the service it MAY include the result code indicating that 
the credit control is not applicable (e.g. service is free of 
charge) . 

For informative purposes, the Accounting-Answer message SHOULD also 
include the Cost-Information AVP containing the estimated total cost 
of the requested service. 

3.2.4 Refund 

There MAY be a need to refund service units on the end user's 
account, for example gaming services. 

The credit control client MUST set Accounting-Record-Type AVP to the 
value EVENT_RECORD and the Requested-Action AVP to REFUND in the 
Accounting-Request message. The Subscription-Id-Data AVP SHOULD be 
included to identify the End-User in the credit control server. 

The Diameter credit control client MAY include the monetary amount to 
be refunded in the Request-Service-Unit AVP, if it knows the cost of 
the service event. If the Diameter credit control client does not 
know the cost of the service event, then the Service-Parameter-Info 
AVP SHOULD contain the service event information to be rated by the 
credit control server. The Service-Parameter-Info AVP always refers 
to the requested service unit. 

For informative purposes, the Accounting-Answer message MAY also 
include the Cost-Information AVP containing the estimated monetary 
amount of refunded unit. 

3.2.5 Failure Procedure 

There MAY exist protocol transparent Diameter relays and redirect 
agents or Diameter credit control proxies between credit control 
client and credit control server. These agents MAY perform failover 
procedures if they detect transport failure as described in 
[DIAMBASE] . 

When the credit control client detects a communication failure to the 
credit control server its behavior depends on the requested action. 
The timer Tx (as defined in section 8) is used in the credit control 
client to supervise the communication with the credit control server. 

In case the requested action is Service Price Enquiry or Balance 
Check and communication failure is detected the credit control client 
MAY forward the request messages to an alternative credit control 
server, if possible. 

If the requested action is DIRECT_DEBITING and the Direct-Debiting- 
Failure-Handling AVP is set to TERMINATE_OR_BUFFER the credit control 
client SHOULD terminate the service if it can determine from the 
result code or error code in the answer message that units have not 
been debited. Otherwise the credit control client SHOULD grant the 
service to the end user and store the record in the credit control 
application level non-volatile storage. The credit control client 
MUST mark these request messages as possible duplicate by setting the 
T-flag in the command header as described in [DIAMBASE] section 3. If 
the Direct-Debiting-Failure-Handling AVP is set to CONTINUE the 
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service SHOULD be granted even if credit control messages can't be 
delivered. If the timer Tx expires the credit control client MUST 
continue the service and eventually buffer the request according to 
the value of the Direct-Debiting-Failure-Handling AVP . 

The Accounting-Request with requested action REFUND should always be 
stored in the credit control application level non-volatile storage 
in case of temporary failure. The credit control client MUST mark the 
re-transmitted request message as possible duplicate by setting the 
T-flag in the command header as described in [DIAMBASE] section 3. 

The implementation MAY choose to limit the number of re-transmission 
attempts and define a re-transmission interval. 

Because there can appear duplicate request for various reason the 
credit control server is therefore responsible for the real time 
duplicate detection. Implementation issues for duplicate detection 
are discussed in [DIAMBASE] Appendix C. When the credit control 
client re-sends messages from its application level non-volatile 
storage it MUST mark these request messages as possible duplicate by 
setting the T-flag in the command headers as described in [DIAMBASE] 
section 3. 

Only one place in the credit control system SHOULD be responsible for 
duplicate detection. If there is only one credit control server 
within the given realm the credit control server MAY perform 
duplicate detection. In case when more than one credit control server 
are supporting the credit control application the accounting manager 
controlling the account database MAY be responsible for duplicate 
detection . 

3.3 Credit Control Session State Machine 

The following state machines MUST be supported for credit control 
applications . 

The first two state machines are to be observed by credit control 
clients. The first one describes the session based credit control and 
the second one event based credit control. The third state machine 
describes the credit control session from a credit control server 
perspective . 

Any event not listed in the state machines MUST be considered as an 
error condition, and a corresponding answer, if applicable, MUST be 
returned to the originator of the message. 

In the state table, the event 'Failure to send' means that the 
Diameter credit control client is unable to communicate with the 
desired destination (i.e. the answer message is not received within 
the validity time of the request) . This could be due to the peer 
being down, or due to a physical link failure in the path to/from the 
credit control server. 

The event 'Temporary error' means that the Diameter credit control 
client received a transient failure notification in the Accounting 
Answer command (i.e. the peer sending back a transient failure or 
temporary protocol error notification DIAMETER_TOO_BUSY, or 
DIAMETER_LOOP_DETECTED in the Result-Code AVP) . 

The event 'Failed answer' means that the Diameter credit control 
client received non-transient failure (permanent failure) 
notification in the Accounting Answer command. 
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The action 'store record' means that a record is stored in the credit 
control application level non-volatile storage. 

The event 'Not successfully processed' means that the credit control 
server could not process the message, e.g. due to unknown end user, 
account being empty or due to errors defined in [DIAMBASE] . 

The states PendingS, PendingI, PendingL PendingE and PendingB stand 
for pending states to wait for an answer to an accounting request 
related to a Start, Interim, Stop, Event or Buffered record 
respectively . 

CLIENT, SESSION BASED 
State Event Action New State 

Idle Client or device requests Send PendingS 

access accounting 

start req. , 
start Tx. 

PendingS Successful accounting Stop Tx Open 

start answer received 

PendingS Failure to send, or Grant Idle 

temporary error and service to 

credit control fault end user 
handling equal to CONTINUE 

PendingS Failure to send, or Disconnect Idle 

temporary error and user/dev 

credit control fault 
handling equal to TERMINATE 

PendingS Tx expired and credit Disconnect Idle 

Control fault handling user/dev 

equal to TERMINATE 

PendingS Tx expired and credit control Grant 

fault handling equal to service to Idle 
CONTINUE end user 

PendingS Accounting start answer Disconnect Idle 
received with result code user/dev 
SERVICE_ DENIED or 
USER_NOT_FOUND 

PendingS Accounting start answer Grant Idle 
received with result code service 
equal to credit control N/A to end user 

PendingS Failed accounting start answer Grant Idle 
received and credit control Service to 
fault handling end user 

equal to CONTINUE 

PendingS Failed accounting start answer Disconnect Idle 
received and credit control user/dev 
failure handling equal to 
TERMINATE 

PendingS User service terminated Queue PendingS 

termination 
event 
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PendingS Change in rating condition 



Queue 

changed 

rating 

condition 

event 



PendingS 



Open Granted unit elapses 
and no final unit 
indication received 



Send 

accounting 
interim req. , 
start Tx. 



PendingI 



Open Granted unit elapses 

and final unit indication 
received 



Disconnect 
send 

accounting 
stop req. , 
start Tx. 



PendingL 



Open Change in rating condition 
in queue 



Send 

accounting 
interim req. , 
Start Tx. 



PendingI 



Open 



Service terminated in queue 



Send 

accounting 
stop req. , 
start Tx 



PendingL 



Open Change in rating condition 
or interim interval elapses 



Send 

accounting 
interim req. , 
Start Tx. 



PendingI 



Open 



User service terminated 



Send 

accounting 
stop req. , 
start Tx 



PendingL 



PendingI Successful accounting interim Stop Tx Open 
answer received 



PendingI Failure to send, or Grant 

temporary error and service to 

credit control fault end user 
handling equal to CONTINUE 



Idle 



PendingI Failure to send, or 
temporary error and 
credit control fault 
handling equal to TERMINATE 



Disconnect 
user/dev 



Idle 



PendingI Tx expired and credit control Disconnect 
fault handling equal to user/dev 
TERMINATE 



Idle 



PendingI Tx expired and credit control Grant 

fault handling equal to service to 
CONTINUE end user. 



Idle 



PendingI Accounting interim answer Disconnect 
received with result code user/dev 
SERVICE_DENIED 



Idle 
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PendingI Accounting interim answer Grant Idle 
received with result code service 
equal to credit control N/A to end user 

PendingI Failed accounting interim Grant Idle 

answer received and credit service to 

control fault handling equal end user, 
to CONTINUE 

PendingI Failed accounting interim Disconnect Idle 
answer received and credit user/dev 
control fault handling 
equal to TERMINATE 

PendingI User service terminated Queue PendingI 

termination 
event 

PendingI Change in rating Queue PendingI 

condition changed 

rating 
condition 
event 

PendingL Successful accounting stop Idle 

answer received 

PendingL Tx expired Idle 

PendingL Failure to send, or temporary Idle 

error or failed answer 

PendingL Change in rating condition PendingL 



CLIENT, EVENT BASED 
State Event Action New State 



Idle Client or device requests Send PendingE 

a one-time service accounting 

event req. , 
Start Tx. 

Idle Records in storage Send PendingB 

stored 
records 

PendingE Successful accounting Idle 

event answer received 

PendingE Failure to send, temporary Indicate Idle 
error or failed accounting service 
event answer received, or error 
Tx expired, requested 
action GET_BALANCE or 
PRICE_ENQUIRY 

PendingE Accounting event answer Disconnect Idle 
received with result code user/dev 
SERVICE_ DENIED or 
USER_NOT_FOUND 
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PendingE Accounting event answer Grant 

received with result code service 

credit control N/A, requested to end 

action DIRECT_DEBITING user 



Idle 



PendingE Failure to send, temporary Grant 

error or failed accounting service 
event answer received, or Tx to end 
expired, requested user 

action DIRECT_DEBITING and 
fault handling equal to 
CONTINUE 



Idle 



PendingE Failed accounting event 

answer received, requested 
action DIRECT_DEBITING and 
fault handling equal to 
TERMINATE OR BUFFER 



Disconnect 
user/dev 



Idle 



PendingE Failure to send or Tx 
expired, requested 
action DIRECT_DEBITING and 
fault handling equal to 
TERMINATE_OR_BUFFER 



Grant 

service 

to end user 

and store 

record with 

T-flag 



Idle 



PendingE Temporary error, requested 
action DIRECT_DEBITING and 
fault handling equal to 
TERMINATE_OR_BUFFER 



Disconnect 
user/dev 



Idle 



PendingE Failed accounting event 

answer received, requested 
action REFUND 



Indicate 
service 
error and 
delete record 



Idle 



PendingE Failure to send or 

Tx expired, requested 
action REFUND 



Store record Idle 
with T-flag 



PendingE Temporary error 

and requested action 
REFUND 



Store record Idle 



PendingB Successful accounting answer Delete 
received record 



Idle 



PendingB Failed accounting answer Delete 
received record 



Idle 



PendingB Failure to send or 
temporary error 



Idle 



State 



Event 



SERVER, SESSION AND EVENT BASED 

Action 



New State 



Idle Accounting start request 
received and successfully 
processed. 



Send 

accounting 
start 
answer. 



Open 
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reserve units, 
start Ts 



Idle Accounting start request 
received, but not 
successfully processed. 



Send 

accounting 
start 

Answer with 
Result-Code 
!= SUCCESS 



Idle 



Idle Accounting event request 
received and successfully 
processed. 



Send 

accounting 
event 
answer, 
debit units 



Idle 



Idle Accounting event request 
received, but not 
successfully processed. 



Send 

accounting 
event 

Answer with 
Result-Code 
!= SUCCESS 



Idle 



Open Accounting Interim request 
received and successfully 
processed 



Send 

accounting 
answer, 
debit used 
units and 
reserve 
new units. 
Restart Ts 



Open 



Open Accounting interim request 
received, but not 
successfully processed. 



Send 

accounting 
interim 
Answer with 
Result-Code 
!= SUCCESS, 
debit used 
units 



Idle 



Open Accounting stop request 

received, and successfully 
processed 



Send 

accounting 
stop answer. 
Stop Ts, 
debit used 
units 



Idle 



Open Accounting stop request 
received, but not 
successfully processed. 



Send 

accounting 
stop 

Answer with 
Result-Code 
!= SUCCESS, 
debit used 
units 



Idle 



Open Session supervision timer Ts 
expired 



Stop Ts, 
release 
reserved 
units 



Idle 



4 Accounting AVPs 
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This section defines the accounting AVPs that are specific to 
Diameter Credit Control Application and MAY be included in the 
Diameter accounting messages [DIAMBASE] . 

Accounting-Request command MAY include the following additional AVPS: 

[ Subscription-Id ] 

[ Requested-Action ] 

* [ Requested-Service Unit ] 

* [ Used-Service-Unit ] 

* [ Service-Parameter-Info ] 

[ Abnormal-Termination-Reason] 

* [ Accounting-Correlation-Id ] 

[ Credit-Control-Failure-Handling ] 

Accounting-Answer command MAY include a following additional AVPS: 

[ Subscription-Id ] 

* [ Granted-Service-Unit ] 

[ Cost-Information] 

[ Final-Unit-Indication ] 

[ Checlc-Balance-Result ] 

[ Credit-Control-Failure-Handling ] 

The following table describes the Diameter AVPs defined in Credit 
Control application, their AVP Code values, types, possible flag 
values and whether the AVP MAY be encrypted. 



+ + 

AVP Flag rules 
+ + + 



Attribute Name 



AVP Section 

Code Defined Data Type 



Abnormal- XXX 4 . 1 Enumerated 

Termination-Reason 
Accounting- XXX 4.2 OctetString 

Correlation- Id 
Check-Balance- XXX 4 . 3 Enumerated 

Result 
Cost-Information XXX 4.5 Grouped 
Credit-Control- XXX 4 . 6 Enumerated 

Failure-Handling 
Direct-Debiting XXX 4.8 Enumerated 

Failure-Handling 
Final-Unit- XXX 4.9 Unsigned32 
Indicator 
Granted-Service- XXX 4.10 Grouped 

Unit 
Requested-Action XXX 4.11 Enumerated 
Requested-Service XXX 4 . 12 Grouped 

Unit 
Service-Parameter XXX 4.14 Grouped 

Info 
Subscription-Id XXX 4.17 Grouped 
Used-Service-Unit XXX 4.22 Grouped 



MUST 

M 

M 

M 

M 
M 

M 

M 

M 

M 
M 



M 
M 



MAY 

P 

P 

P 

P 
P 

P 

P 

P 

P 
P 



SHLD 
NOT 



s 




+ 

MAY 1 


MU£ 


T 


NOT 


Encr 1 


V 




Y 1 


V 




Y 1 


V 




Y 1 


V 




Y 1 


V 




Y 1 


V 




Y 1 


V 




Y 1 


V 




Y 1 


V 




Y 1 


V 




Y 1 


V 




Y 1 


V 




Y 1 


V 




Y 1 



4.1 Abnormal-Termination-Reason AVP 

The Abnormal-Termination-Reason AVP (AVP Code TBD) is of type 
Enumerated and contains information about the reason for an abnormal 
service termination in a service element. 
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The following reasons are defined: 

SERVICE_ELEMENT_TERMINATION 

An error occurred in the service element. 

CONNECTION_TO_END-USER_BROKEN 1 

The connection to the end-user is broken. 

4.2 Accounting-Correlation-Id AVP 

The Accounting-Correlation-Id AVP (AVP Code TBD) is type of 
OctetString and contains information to correlate accounting data 
generated for different components of the service, e.g. transport and 
service level. 

4.3 Check-Balance-Result AVP 

The Check Balance Result AVP (AVP code TBD) is of type Enumerated and 
contains the result of the balance check. This AVP is applicable only 
when the Requested-Action AVP indicates CHECK_BALANCE in the 
Accounting-Request command. 

The following values are defined for the Check-Balance-Result AVP. 

ENOUGH_CREDIT 

There is enough credit in the account to cover the requested 
service . 

NO_CREDIT 1 

There isniEt enough credit in the account to cover the 
requested service. 

4.4 Cost-Information AVP 

The Cost-Information AVP (AVP Code TBD) is of type Grouped and is 
used to return the cost information of a service in the Accounting- 
Answer command. The included Unit-Value AVP contains the cost 
estimate (always type of money) of the service in case of price 
enquiry or the accumulated cost estimation in the case of credit 
control session. 
The Currency-Code specifies in which currency the cost was given. 

When the Requested-Action AVP with value PRICE_ENQUIRY is included in 
the Accounting-Request command the Cost-Information AVP sent in the 
succeeding Accounting-Answer command contains the cost estimation of 
the requested service, without any reservation being made. 

The Cost-Information AVP included in the Accounting-Answer command 
with the Accounting-Record-Type set to INTERIM_RECORD contains the 
accumulated cost estimation for the session without taking any 
credit-reservation into account. 

The Cost-Information AVP included in the Accounting-Answer command 
with the Accounting-Record-Type set to EVENT_RECORD or STOP_RECORD 
contains the estimated total cost for the requested service. 

It has the following ABNF grammar: 

<Cost-Information> : :=< AVP Header: TBD > 

{ Unit-Value } 
{ Currency-Code } 

4.5 Credit-Control-Failure-Handling AVP 
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The Credit-Control-Failure-Handling AVP (AVP Code TBD) is of type 
Enumerated. The credit control client uses information in this AVP to 
decide what to do if the sending of credit control messages to the 
credit control server has been for instance temporarily prevented due 
to a network problem. 

TERMINATE 

When the Credit-Control-Failure-Handling AVP is set to TERMINATE 
the service MUST only be granted as long as there is a 
connection to the credit control server. If the credit control 
client does not receive any Accounting-Answer message within the 
Tx timer (as defined in section 8) the credit control request 
is regarded failed. The moving of already started credit control 
session to alternative server is not allowed. 

This is the default behaviour if the AVP isn't included in the 
reply from the authorization or credit control server. 

CONTINUE 1 

When the Credit-Control-Failure-Handling AVP is set to CONTINUE 

the service SHOULD be granted even if credit control messages 
can't be delivered. 

4 . 6 Currency-Code AVP 

The Currency-Code AVP (AVP Code TBD) is of type Unsigned32 and 
contains a currency code that specifies in which currency the values 
of AVPs containing monetary units were given. It is specified using 
the numeric values defined in the ISO 4217 standard. 

4.7 Direct-Debiting-Failure-Handling AVP 

The Direct-Debiting-Failure-Handling AVP (AVP Code TBD) is of type 
Enumerated. The credit control client uses information in this AVP to 
decide what to do if the sending of credit control messages 
(Requested-Action AVP set to Direct Debiting) to the credit control 
server has been for instance temporarily prevented due to a network 
problem. 

TERMINATE_OR_BUFFER 

When the Direct-Debiting-Failure-Handling AVP is set to 
TERMINATE_OR_BUFFER the service MUST be granted as long as there 
is a connection to the credit control server. If the credit 
control client does not receive any Accounting-Answer message 
within the Tx timer (as defined in section 8) the credit control 
request is regarded failed. The client SHOULD terminate the 
service if it can determine from the failed answer that units 
have not been debited. Otherwise the credit control client 
SHOULD grant the service, store the request to application level 
non-volatile storage and try to re-send the request. These 
requests MUST be marked as possible duplicate by setting the T- 
flag in the command header as described in [DIAMBASE] section 3. 

This is the default behaviour if the AVP isn't included in the 
reply from the authorization server. 

CONTINUE 1 

When the Direct-Debiting-Failure-Handling AVP is set to CONTINUE 
the service SHOULD be granted even if credit control messages 
can't be delivered. 

4 . 8 Exponent AVP 
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Exponent AVP is of type Integer32 (AVP code TBD) and contains the 
exponent value to be applied for the Value-Digit AVP within the Unit- 
Value AVP . 

4.9 Final-Unit-Indication AVP 

The Final-Unit-Indication AVP (AVP Code TBD) is of type Unsigned32 
and indicates that the Granted-Service-Unit AVP in the accounting 
command contains the final units for the service. After these units 
have expired, the Diameter credit control client in a service element 
is responsible for terminating the service and sending the 
STOP_RECORD to the credit control server. 

If more than one unit types are received in the Accounting-Answer, 
the Unit type which first expired SHOULD cause the termination. 
If included in a command, the value of this AVP is always 1. 

4.10 Granted-Service-Unit AVP 

Granted-Service-Unit AVP (AVP Code TBD) is of type Grouped and 
contains the amount of units that the Diameter credit control client 
can provide to the end user until the service must be released or the 
new Accounting-Request must be sent. The Unit-Value AVP contains the 
granted units and the Unit-Type AVP defines the type of the unit. 

If the Unit-Type AVP is set to time in the Accounting-Answer command, 
the Unit Value AVP specifies the granted time in seconds. 

If the Unit-Type AVP is set to volume in the Accounting-Answer 
command, the Unit-Value AVP specifies the granted volume in bytes. 

If the Unit-Type AVP is set to service specific in the Accounting- 
Answer command, the Unit-Value AVP specifies the granted number of 
service specific units (e.g. number of events, points) given in a 
selected service. 

If the Unit-Type AVP is set to money in the Accounting-Answer 
command, the Unit-Value AVP specifies the granted monetary amount in 
the given currency. If the unit type is money, a Currency-Code AVP 
SHOULD be included. 

It has the following ABNF grammar: 

<Granted-Service-Unit> : :=< AVP Header: TBD > 

{ Unit-Type } 

{ Unit-Value } 

[ Currency-Code ] 

4.11 Requested-Action AVP 

The Requested-Action AVP (AVP Code TBD) is type of Enumerated and 
contains the requested action being sent by Accounting-Request 
command where the Accounting-Record-Type is set to EVENT_RECORD . 
The following values are defined for the Requested-Action AVP: 

DIRECT DEBITING 

Direct debiting indicates that the request is to decrease the 
end user's account according to information specified in the 
Requested-Service-Unit AVP and/or Service-Parameter-Info AVP. 
The Granted-Service Unit AVP in the Accounting-Answer command 
contains the debited units. 

REFUND ACCOUNT 1 

Refund account indicates that the request is to increase the end 
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user's account according to information specified in the 
Requested-Service-Unit AVP and/or Service-Parameter-Info AVP . 
The Granted-Service Unit AVP in the Accounting-Answer command 
contains the refunded units. 

CHECK_BALANCE 2 

Check balance indicates that the request is a balance check 
request. In this case the checking of the account balance is 
done without any credit reservation from the account. The Check- 
Balance-Result AVP in the Accounting-Answer command contains the 
result of the Balance Check. 

PRICE_ENQUIRY 3 

Price Enquiry indicates that the request is a price enquiry 
request. In this case neither checking of the account balance 
nor reservation from the account will be done, only the price of 
the service will be returned in the Cost-Information AVP in the 
Accounting-Answer Command. 

4.12 Requested-Service-Unit AVP 

The Requested-Service-Unit AVP (AVP Code TBD) is of type Grouped and 
contains the amount of requested units specified by the Diameter 
credit control client. The included Unit-Value AVP contains the 
requested Unit-Value and the Unit-Type AVP defines the type of the 
unit . 

If the Unit Type AVP is set to time in the Accounting-Request 
command, the Unit-Value AVP specifies the requested time in seconds. 

If the Unit-type AVP is set to volume in the Accounting-Request 
command, the Unit-Value AVP specifies the requested volume in bytes. 

If the Unit-type AVP is set to service specific in the Accounting- 
Request command, the Unit-Value AVP specifies the used number of 
service specific units (e.g. number of events) given in a selected 
service . 

If the Unit-Type AVP is set to money in the Accounting-Request 
command, the Unit-Value AVP specifies the monetary amount in the 
given currency. If the unit type is money, a Currency-Code AVP SHOULD 
be included. 

It has the following ABNF grammar: 

<Requested-Service-Unit> : :=< AVP Header: TBD > 

{ Unit-Type } 
{ Unit-Value } 
[ Currency-Code ] 

4.13 Service-Parameter-Info AVP 

The Service-Parameter-Info AVP (AVP Code TBD) is of type Grouped and 
contains a service specific information used for price calculation or 
rating. The Service-Parameter-Type AVP defines the service parameter 
type and the Service-Parameter-Value AVP contains the parameter 
value. Alternatively it MAY also contain lANA registered standard 
AVPs or vendor specific AVPs. The actual contents of these AVPs are 
not within the scope of this document and SHOULD be defined in 
another Diameter application, standards written by other 
standardization bodies, or service specific documentation. 
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In case of unknown service request (e.g. unknown AVP or Service- 
Parameter-Type), the corresponding answer message MUST contain error 
code DIAMETER_AVP_UNSUPPORTED or DIAMETER_INVALID_AVP_VALUE . An 
Accounting Answer message with these errors MUST contain one or more 
FAILED-AVP AVPs containing the AVPs that caused the failure. 

It has the following ABNF grammar: 

<Service-Parameter-Info> : :=< AVP Header: TBD > 

[ Service-Parameter-Type ] 
[ Service-Parameter-Value ] 
[ AVP ] 

4.14 Service-Parameter-Type AVP 

The Service-Parameter-Type AVP is of type Unsigned32 (AVP Code TBD) 
and defines the type of the service event specific parameter (e.g. it 
can be end-user location, service name) . The different parameters and 
their types are service specific and the meanings of these parameters 
are not defined in this document. The Service-Parameter-Value AVP 
contains the service parameter type. 

4.15 Service-Parameter-Value AVP 

The Service-Parameter-Value AVP is of type UTFSString (AVP Code TBD) 
and contains the value of the service parameter type. 

4.16 Subscription-Id AVP 

The Subscription-Id AVP (AVP Code TBD) is used to identify the end 
useriEs subscription and is of type Grouped. The Subscription-Id AVP 
includes a Subscription-Id-Data AVP that hold the identifier and a 
Subscription-Id-Type AVP that defines the identifier type. 

It has the following ABNF grammar: 

<Subscription-Id> : :=< AVP Header: TBD > 

{ Subscription-Id-Data } 
{ Subscription-Id-Type } 

4.17 Subscription-Id-Data AVP 

The Subscription-Id-Data AVP (AVP Code TBD) is used to identify the 
end-user and is of type UTFSString. The Subscription-Id-Type AVP 
defines which type of identifier is used. 

4.18 Subscription-Id-Type AVP 

The Subscription-Id-Type AVP (AVP Code TBD) is of type Enumerated and 
it is used to determine which type of identifier that is carried by 
the Subscription-Id AVP. 

The identifier can be one of the following: 

END_USER_MSISDN 

The identifier is in international MSISDN format, according 
to the ITU-T E.164 numbering plan as defined in [E164] and 
[CE164] . 

END_USER_IMSI 1 

The identifier is in international IMSI format, according to 
the ITU-T E.212 numbering plan as defined in [E121] and 
[CE121] . 
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END_USER_SIP_URL 2 

The identifier is in the form of a SIP URL as defined in 
[SIP] . 

END_USER_NAI 3 

The identifier is in the form of a Network Access Identifier 
as defined in [NAT] . 

END_USER_PRIVATE 4 

The Identifier is a credit control server private identifier. 

4.19 Unit-Type AVP 

The Unit-Type AVP is of type Enumerated (AVP Code TBD) and contains 

the type of the unit . 

The unit type can be one of the following: 

CREDIT_TYPE_TIME 

The unit is of type time, given in seconds. 

CREDIT_TYPE_VOLUME 1 

The unit is of type volume, given in bvtes. 

CREDIT_TYPE_SERVICE_SPECIFIC 2 

The unit is service specific (e.g. number of events, 
points, chips, services etc), given in a selected service. 

CREDIT_TYPE_MONEY 3 

The unit is of type money, given as a monetary value, whose 
currency SHOULD be specified by the Currency-Code AVP. 

4.20 Unit-Value AVP 

Unit-Value AVP is of type Grouped (AVP Code TBD) . The value can be 
time in seconds, volume in bytes, number of service specific units or 
monetary amount depending on the given unit type. The Unit-Value is a 
value together with an exponent, i.e. Unit-Value = Value-Digits AVP * 
lO'^Exponent . This representation avoids unwanted rounding off. For 
example the value of 2,3 is represented as Value-Digits = 23 and 
Exponent = -1. The absence of exponent part MUST be interpreted as 
exponent being equal to zero. 

It has the following ABNF grammar: 

<Unit-Value>: :=< AVP Header: TBD > 
{ Value-Digits } 
[ Exponent ] 

4.21 Used-Service-Unit AVP 

The Used-Service-Unit AVP is of type Grouped AVP (AVP Code TBD) and 
contains the amount of used units measured from the point when the 
service became active or, in case of interim interrogations are used 
during the session, from the point when the previous measurement 
ended. The included Unit-Type AVP defines the type of the unit and 
the Unit-Value AVP contains the used amount. 

If the Unit Type AVP is set to time in the Accounting-Request 
command, the Unit-Value AVP specifies the used time in seconds. 

If the Unit-Type AVP is set to volume in the Accounting-Request 
command, the Unit-Value AVP specifies the used volume in bytes. 
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If the Unit-type AVP is set to service specific in the Accounting- 
Request command, the Unit-Value AVP specifies the used number of 
service specific units (e.g. number of events) given in a selected 
service . 

If the Unit-Type AVP is set to money in the Accounting-Request 

command, the Unit-Value AVP specifies the used monetary amount in the 

given currency. If the unit type is money, a Currency-Code AVP SHOULD 
be included. 

It has the following ABNF grammar: 

<Used-Service-Unit>: :=< AVP Header: TBD > 

{ Unit-Type } 
{ Unit-Value } 
[ Currency-Code ] 

4.22 Value-Digits AVP 

The Value-Digits AVP is of type Unsigned64 (AVP code TBD) and 
contains the number of seconds, volume in bytes, number of service 
specific units or monetary amount depending on the given Unit-Type 
AVP. If decimal values are needed to present the units, the scaling 
MUST be indicated with the related Exponent AVP. For example for the 
monetary amount $ 0,05 the value of Value-Digits AVP MUST be set to 5 
and the scaling MUST be indicated with the Exponent AVP set to u2 . 

5 Result Code AVP values 

This section defines new Result-Code AVP [DIAMBASE] values that must 
be supported by all Diameter implementations that conform to this 
specification . 

The Accounting-Answer message includes the Result-Code AVP, which MAY 
indicate that an error was present in the Accounting-Request message. 
A rejected Accounting-Request message SHOULD cause the useriEs session 
to be terminated. 

5.1 Transient Failure 

Errors that fall within the transient failures category are used to 
inform a peer that the request could not be satisfied at the time it 
was received, but MAY be able to satisfy the request in the future. 

DIAMETER_END_USER_SERVICE_DENIED 4 0XX 

The credit control server denies the service request due to 
service restrictions or limitations related to the end-user, 
for example the end-user's account could not cover the requested 
service . 

DIAMETER_CREDIT_CONTROL_NOT_APPLICABLE 4 0XX 

The credit control server determines that the service can be 
granted to the end user but no further credit control is needed 
for the service (e.g. service is free of charge) . 

5.2 Permanent Failures 

Errors that fall within permanent failure category are used to inform 
the peer that the request failed, and should not be attempted again. 

DIAMETER_USER_UNKNOWN 5 0XX 

The specified end user is unknown in the credit control server. 
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6 AVP Occurrence Table 

The following table presents the AVPs defined in this document, and 
specifies in which Diameter messages they MAY, or MAY NOT be present. 
Note that AVPs that can only be present within a Grouped AVP are not 
represented in this table. 

The table uses the following symbols: 




+ 

0-1 



1 
1 + 



The AVP MUST NOT be present in the message. 

Zero or more instances of the AVP MAY be present in the 

message . 

Zero or one instance of the AVP MAY be present in the 

message. It is considered an error if there are more than 

once instance of the AVP. 

One instance of the AVP MUST be present in the message. 

At least one instance of the AVP MUST be present in the 

message . 



6.1 Accounting AVP Table 

The table in this section is used to represent which Credit Control 
applications specific AVPs defined in this document are to be present 
in the accounting messages. 



Attribute Name 



+ + 

Command | 
Code I 

+ + 

ACR I ACA I 




Abnormal -Termination-Re a son 
Accounting-Correlation- Id 
Credit -Control-Failure- 
Handling 

Check-Balance-Result 
Cost -Information 
Direct -Debit ing-Fai lure- 
Handling AVP 
Final-Unit -Indication 
Granted- Service -Unit 
Requested-Action 
Requested- Service -Unit 
Service-Parameter- Info 
Sub script ion- Id 
Used- Service -Unit 



7 lANA Considerations 

This section contains the namespaces that have either been created in 
this specification, or the values assigned to existing namespaces 
managed by lANA. 

7.1 Application Identifier 

This specification assigns the value TBD to the Application 
Identifier namespace defined in [DIAMBASE] . See section 1.3 for more 
information . 

7.2 Command Codes 

This specification uses the value 271 from the Command code namespace 
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defined in [DIAMBASE] . 

7.3 AVP Codes 

This specification assigns the values TBD - TED from the AVP code 
namespace defined in [DIAMBASE] See section 4.0 for the assignment of 
the namespace in this specification. 

7.4 Result-Code AVP Values 

This specification assigns the values 40XX and 50XX from the Result- 
Code AVP (AVP Code 268) value namespace defined in [DIAMBASE] . See 
section 5.0 for the assignment of the namespace in this 
specification . 

7.5 Abnormal-Termination-Reason AVP 

As defined in Section 4.1, the Abnormal-Termination-Reason AVP (AVP 
Code TBD) defines the values 0-1. All remaining values are available 
for assignment via Designated Expert [lANA] . 

7.6 Check-Balance-Result AVP 

As defined in Section 4.3, the Check-Balance-Result AVP (AVP Code 
TBD) defines the values 0-1. All remaining values are available for 
assignment via Designated Expert [lANA] . 

7.7 Credit-Control-Failure-Handling AVP 

As defined in Section 4.6, the Credit-Control-Failure-Handling AVP 
(AVP Code TBD) defines the values 0-1. All remaining values are 
available for assignment via Designated Expert [lANA] . 

7.8 Direct-Debiting-Failure-Handling AVP 

As defined in Section 4.8, the Direct-Debiting-Failure-Handling AVP 
(AVP Code TBD) defines the values 0-1. All remaining values are 
available for assignment via Designated Expert [lANA] . 

7.9 Requested-Action AVP 

As defined in Section 4.11, the Requested-Action AVP (AVP Code TBD) 
defines the values 0-3. All remaining values are available for 
assignment via Designated Expert [lANA] . 

7.10 Subscription-Id-Type AVP 

As defined in Section 4.17, the Subscription-Id-Type AVP (AVP Code 
TBD) defines the values 0-4. All remaining values are available for 
assignment via Designated Expert [lANA] . 

7.11 Unit-Type AVP 

As defined in Section 4.20, the Unit-Type AVP (AVP Code TBD) defines 
the values 0-3. All remaining values are available for assignment via 
Designated Expert [TANA] . 

8 Credit Control Application related parameter 

Tx timer 

When real-time credit control is required, the credit control 
client contacts the credit control server before and during the 
service is provided to an end user. Due to real-time nature of 
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application the communication delays SHOULD be minimized, e.g. to 

avoid too long service set up time experienced by the end user. The 

Tx timer is introduced to control the waiting time in the client in 
the PENDING state. 

The recommended value is 10 seconds. 

9 Security Considerations 

The security models as defined in the Diameter base protocol 
[DIAMBASE] applies to this application too. 
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